[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