bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#36823: gcc bug prevents go program from starting newer gcc results i


From: Malte Frank Gerdes
Subject: bug#36823: gcc bug prevents go program from starting newer gcc results in race condition
Date: Tue, 06 Jul 2021 15:14:30 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Thanks for your answer :-)

I don't use hugo anymore but at least i now know what the problem was,
but i really appreciate that you took the time to reproduce this. Does
it make sense to keep this ticket open, because as you found out there
still /is/ a bug? 

(also just rediscovering the subject line: what the heck did i mean with
that?!)


Malte

Sarah Morgensen <iskarian@mgsn.dev> writes:

> Hello,
>
> Thanks for the report.
>
> Malte Frank Gerdes <malte.f.gerdes@gmail.com> writes:
>
>> Hi,
>>
>> The precompiled version of Hugo-extended was not able to find some
>> runtime dependencies:
>>    libstdc++.so.6  => not found
>>    libgcc_s.so.1   => not found
>
> In case you haven't discovered this in the past two years (oops), this
> is because Guix does not typically work with pre-compiled software that
> relies on system libraries being in /lib, since there is no system-wide
> /lib.
>
>> This seems like a version mismatch to me, so i built Hugo with the
>> following command:
>>   go build --tags extended
>>
>> Now the error is (<HASH> = ypiv8dj4lkvsnm82s639h18l87frrh5g):
>>   /gnu/store/<HASH>-gcc-6.5.0-lib/lib/libstdc++.so.6: version
>>   `GLIBCXX_3.4.26' not found
>
> If I build hugo with gcc-toolchain@7 in my user profile, it works fine.
> However.... I can still repro this issue with gcc-toolchain@8+:
>
> $ go build --tags extended
> $ ./hugo --help
> ./hugo: 
> /gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib/lib/libstdc++.so.6: 
> version `GLIBCXX_3.4.26' not found (required by ./hugo)
> ./hugo: 
> /gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib/lib/libstdc++.so.6: 
> version `GLIBCXX_3.4.29' not found (required by ./hugo)
>
> This is because gcc 7's libraries are shadowing the newer gcc's
> libraries:
>
> $ readelf -d hugo | grep RUNPATH
>  0x000000000000001d (RUNPATH) Library runpath:
> [/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib/lib:/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib:/gnu/store/3h7xd0d47a286b6r9qhz4ybi5iaxkfwi-gcc-11.1.0-lib/lib:/home/sarah/.guix-profile/lib:/gnu/store/3h7xd0d47a286b6r9qhz4ybi5iaxkfwi-gcc-11.1.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.1.0/../../..]
>
> If I use patchelf to remove the gcc 7 library dir from RUNPATH, hugo
> works fine. This is because Go is patched to unconditionally add a
> runpath to gcc 7's libraries but erroneously does not explicitly set
> CXX. (See also <https://issues.guix.gnu.org/39400>.)
>
> The following patch should explicitly set CXX for Go, so that it always
> uses the "system" version:
>
> diff --git a/gnu/packages/golang.scm b/gnu/packages/golang.scm
> index 0318918a37..a27f57aa30 100644
> --- a/gnu/packages/golang.scm
> +++ b/gnu/packages/golang.scm
> @@ -395,6 +395,7 @@ in the style of communicating sequential processes 
> (@dfn{CSP}).")
>                 ;; FIXME: Some of the .a files are not bit-reproducible.
>                 (let* ((output (assoc-ref outputs "out")))
>                   (setenv "CC" (which "gcc"))
> +                 (setenv "CXX" (which "g++"))
>                   (setenv "GOOS" "linux")
>                   (setenv "GOROOT" (dirname (getcwd)))
>                   (setenv "GOROOT_FINAL" output)
> @@ -577,6 +578,7 @@ in the style of communicating sequential processes 
> (@dfn{CSP}).")
>                        (loader (string-append (assoc-ref inputs "libc")
>                                               ,(glibc-dynamic-linker))))
>                   (setenv "CC" (which "gcc"))
> +                 (setenv "CXX" (which "g++"))
>                   (setenv "GO_LDSO" loader)
>                   (setenv "GOOS" "linux")
>                   (setenv "GOROOT" (dirname (getcwd)))
>
>
> Hope that helps,
> Sarah





reply via email to

[Prev in Thread] Current Thread [Next in Thread]