Hello. I am building "i686-gentoo-linux-musl" toolchain using crossdev. Second gcc stage failed with "configure: error: Pthreads are required to build libatomic". Please see build.log here. https://gist.github.com/andrew-aladev/b11eae6991a5358172f98ee14e1b2917 This issue is "i686" specific, "x86_64" works perfect. Reproducible: Always
> Please see build.log here. > https://gist.github.com/andrew-aladev/b11eae6991a5358172f98ee14e1b2917 > Please attach the log so we have a record in bugzilla. Thanks.
I've debuged this issue a bit and found the reason: conftest.err: /usr/libexec/gcc/i686-gentoo-linux-musl/ld: /var/tmp/portage/cross-i686-gentoo-linux-musl/gcc-9.2.0-r2/temp/cc9ac3JU.o: in function `main': /var/tmp/portage/cross-i686-gentoo-linux-musl/gcc-9.2.0-r2/work/build/i686-gentoo-linux-musl/libatomic/conftest.c:71: undefined reference to `__stack_chk_fail_local' /usr/libexec/gcc/i686-gentoo-linux-musl/ld: conftest: hidden symbol `__stack_chk_fail_local' isn't defined /usr/libexec/gcc/i686-gentoo-linux-musl/ld: final link failed: bad value collect2: error: ld returned 1 exit status This issue is very famous. I don't think we should report it to upstream - everybody reports it several times per year =). The workaround is simple - just disable ssp use: USE="-ssp" crossdev -t i686-gentoo-linux-musl --stable And it works perfect. PS you don't need to disabled stack protector manually when emerging "sys-devel/gcc" inside i686 musl container - it will be disabled automatically. This is just an issue linked with wrong guessing about stack protector support while cross compiling.
> Please attach the log so we have a record in bugzilla. Thanks. Bugzilla has 1 mb limit only, it is not possible to attach, sorry.
Created attachment 604142 [details] build log
(In reply to Andrew Aladjev from comment #2) > I've debuged this issue a bit and found the reason: > > conftest.err: > /usr/libexec/gcc/i686-gentoo-linux-musl/ld: > /var/tmp/portage/cross-i686-gentoo-linux-musl/gcc-9.2.0-r2/temp/cc9ac3JU.o: > in function `main': > /var/tmp/portage/cross-i686-gentoo-linux-musl/gcc-9.2.0-r2/work/build/i686- > gentoo-linux-musl/libatomic/conftest.c:71: undefined reference to > `__stack_chk_fail_local' > /usr/libexec/gcc/i686-gentoo-linux-musl/ld: conftest: hidden symbol > `__stack_chk_fail_local' isn't defined > /usr/libexec/gcc/i686-gentoo-linux-musl/ld: final link failed: bad value > collect2: error: ld returned 1 exit status > > This issue is very famous. I don't think we should report it to upstream - > everybody reports it several times per year =). That looks like effect of misconfigured gcc or miscompiled musl but not the reason itself. If musl configurations don't support any form of ssp we can work it around in crossdev or in gcc ebuilds. > The workaround is simple - just disable ssp use: > USE="-ssp" crossdev -t i686-gentoo-linux-musl --stable > > And it works perfect. > > PS you don't need to disabled stack protector manually when emerging > "sys-devel/gcc" inside i686 musl container - it will be disabled > automatically. This is just an issue linked with wrong guessing about stack > protector support while cross compiling. Given that we force-mask that USE-flag at https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=deb72d3a8b4e6f37c9191a229bbe19affa597492 i don't think gcc is guessing at all at this point. USE=ssp just asks gcc to enable it via --enable-default-ssp. I don't see a stated reason to disable ssp. Especially why it's done selectively on x86 but not on amd64. musl git repository clearly tries to provide minimal support for SSP helpers regardless of targets: https://git.musl-libc.org/cgit/musl/tree/src/env/__stack_chk_fail.c
Yes, it is an old musl defect. I am not sure why it is still not fixed, maybe some political questions. Please see here https://gitweb.gentoo.org/repo/gentoo.git/tree/profiles/default/linux/x86/17.0/musl/use.mask It is still broken today. So I think crossdev can disable "ssp" in the same way as internal portage profile. "x86_64" version of stack protector works perfect, I've just created complete docker image yesterday: "puchuu/test_x86_64-gentoo-linux-musl". There are bunch of discussions in musl mailing lists about this issue.
https://www.openwall.com/lists/musl/2014/03/22/8 https://git.alpinelinux.org/aports/tree/main/musl/APKBUILD It looks like musl is not going to fix this issue. It was fixed in alpine by providing separate libssp_nonshared which replaced libssp from gcc.
(In reply to Andrew Aladjev from comment #7) > https://www.openwall.com/lists/musl/2014/03/22/8 > https://git.alpinelinux.org/aports/tree/main/musl/APKBUILD > > It looks like musl is not going to fix this issue. It was fixed in alpine by > providing separate libssp_nonshared which replaced libssp from gcc. I don't see the details that describe why that happens. Only hints that libssp happens to be provided by gcc and not by musl. That sounds like a gcc misconfiguration. But does not explain why i386 is different from amd64.
(In reply to Sergei Trofimovich from comment #8) > But does not explain why i386 is different from amd64. Aha, glibc's implementation of __stack_chk_fail_local actually sheds some light: https://sourceware.org/git/?p=glibc.git;a=blob;f=debug/stack_chk_fail_local.c;h=5d6dc84e6b6d9801b34b2b62a1f8ac28ce22c3ff;hb=HEAD#l39 39 /* On some architectures, this helps needless PIC pointer setup 40 that would be needed just for the __stack_chk_fail call. */ Which makes sense. If PLT resolution requires more auxiliary calls it might not be safe to do with already broken stack. Looking at gcc we can check which targets require local equivalent of that. These are: gcc $ git grep -C4 default_hidden_stack_protect_fail | cat i386 (and maybe x32?): gcc/config/i386/i386.c-ix86_stack_protect_fail (void) gcc/config/i386/i386.c-{ gcc/config/i386/i386.c- return TARGET_64BIT gcc/config/i386/i386.c- ? default_external_stack_protect_fail () gcc/config/i386/i386.c: : default_hidden_stack_protect_fail (); gcc/config/i386/i386.c-} ppc/ppc64: gcc/config/rs6000/rs6000.c-rs6000_stack_protect_fail (void) gcc/config/rs6000/rs6000.c-{ gcc/config/rs6000/rs6000.c- return (DEFAULT_ABI == ABI_V4 && TARGET_SECURE_PLT && flag_pic) gcc/config/rs6000/rs6000.c: ? default_hidden_stack_protect_fail () gcc/config/rs6000/rs6000.c- : default_external_stack_protect_fail (); gcc/config/rs6000/rs6000.c-} It's unfortunate musl does not provide '__stack_chk_fail_local' one-liner.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a5f9cdf12da7316370f0cd74d3fc9b4a29d75512 commit a5f9cdf12da7316370f0cd74d3fc9b4a29d75512 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2020-01-24 23:53:08 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2020-01-24 23:53:53 +0000 profiles/default/linux/x86/17.0/musl/use.mask: add a link to ssp problems Bug: https://bugs.gentoo.org/706210 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> profiles/default/linux/x86/17.0/musl/use.mask | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Found more recent post that claims that __stack_chk_fail_local should be provided by libgcc.a: https://www.openwall.com/lists/musl/2018/09/11/2 Not sure I agree given that is a policy decision to implement a way to crash a binary.
(In reply to Sergei Trofimovich from comment #11) > Found more recent post that claims that __stack_chk_fail_local should be > provided by libgcc.a: https://www.openwall.com/lists/musl/2018/09/11/2 > > Not sure I agree given that is a policy decision to implement a way to crash > a binary. I discussed this issue with upstream musl years ago. They will not budge on it, although I agree with you. I've been thinking of adding our own (ie Gentoo specific) implementation of __stack_chk_fail_local() so we can add ssp to x86/musl.
(In reply to Anthony Basile from comment #12) > (In reply to Sergei Trofimovich from comment #11) > > Found more recent post that claims that __stack_chk_fail_local should be > > provided by libgcc.a: https://www.openwall.com/lists/musl/2018/09/11/2 > > > > Not sure I agree given that is a policy decision to implement a way to crash > > a binary. > > I discussed this issue with upstream musl years ago. They will not budge on > it, although I agree with you. I've been thinking of adding our own (ie > Gentoo specific) implementation of __stack_chk_fail_local() so we can add > ssp to x86/musl. Do you have a link to the discussion? I wonder if we can get upstreams to agree on common plan.
Sent https://www.openwall.com/lists/musl/2020/01/25/2 hoping to get some clarity how it should actually made to work. Until it's sorted I'll disable ssp support in toolchain.eclass.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/crossdev.git/commit/?id=3756849289a449ff09e329aaa7e26fbd5739805e commit 3756849289a449ff09e329aaa7e26fbd5739805e Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2020-01-25 11:20:53 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2020-01-25 11:20:53 +0000 crossdev: disable default ssp support on x86 and ppc on musl Set USE=-ssp by default. User can still manually override via environment variable to see how it breaks: USE=ssp crossdev -t i686-gentoo-linux-musl Reported-by: Andrew Aladjev Bug: https://bugs.gentoo.org/706210 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> crossdev | 3 +++ 1 file changed, 3 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=385f248b765e327e6eccaf423c55e0f2f82a3e4b commit 385f248b765e327e6eccaf423c55e0f2f82a3e4b Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2020-01-25 21:45:35 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2020-01-25 21:45:48 +0000 sys-devel/crossdev: bump up to 20200125 Two new changes: - disable default ssp support on x86 and ppc on musl, bug #706210 - migrate from package.keywords to package.accept_keywords, bug #706212 Bug: https://bugs.gentoo.org/706210 Closes: https://bugs.gentoo.org/706212 Package-Manager: Portage-2.3.85, Repoman-2.3.20 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-devel/crossdev/Manifest | 1 + sys-devel/crossdev/crossdev-20200125.ebuild | 36 +++++++++++++++++++++++++++++ 2 files changed, 37 insertions(+)
new crossdev should not fail by default. Let' keep the bug open until upstream agrees where the fix should be. Rich Felker outlined possible solution entirely on gcc side.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=038685f3027f01ed1665878a13f3c9663e7b5209 commit 038685f3027f01ed1665878a13f3c9663e7b5209 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-11-21 11:45:07 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-21 11:46:31 +0000 profiles/default/linux/x86/17.0/musl: unmask SSP We've imported GCC (with its patches) from ::musl and SSP should be fine with x86 (and any other arch) for Gentoo + musl now. In fact, USE=ssp just controls the default, -fstack-protector has been & is working already, so this is just about bringing hardening to x86 users now. Bug: https://bugs.gentoo.org/706210 Bug: https://bugs.gentoo.org/747346 Signed-off-by: Sam James <sam@gentoo.org> profiles/default/linux/x86/17.0/musl/use.mask | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/crossdev.git/commit/?id=7f338ea13570c1d729177425097bf9a72491b902 commit 7f338ea13570c1d729177425097bf9a72491b902 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-11-21 13:07:54 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-21 13:07:54 +0000 Revert "crossdev: disable default ssp support on x86 and ppc on musl" This should be working now -- we've imported fixed GCC to ::gentoo from the musl overlay and we've unmasked + re-enabled SSP everywhere other than crossdev anyway. Bug: https://bugs.gentoo.org/706210 This reverts commit 3756849289a449ff09e329aaa7e26fbd5739805e. Signed-off-by: Sam James <sam@gentoo.org> crossdev | 3 --- 1 file changed, 3 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ae860c5f54606ac8002b06666436235acd80e819 commit ae860c5f54606ac8002b06666436235acd80e819 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-11-22 07:10:21 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-22 07:10:21 +0000 sys-devel/crossdev: add 20211121 Bug: https://bugs.gentoo.org/706210 Signed-off-by: Sam James <sam@gentoo.org> sys-devel/crossdev/Manifest | 1 + sys-devel/crossdev/crossdev-20211121.ebuild | 36 +++++++++++++++++++++++++++++ sys-devel/crossdev/crossdev-99999999.ebuild | 2 +- 3 files changed, 38 insertions(+), 1 deletion(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f679c94c410ce0678a8e8b06952421094f3c2f5e commit f679c94c410ce0678a8e8b06952421094f3c2f5e Author: Sam James <sam@gentoo.org> AuthorDate: 2021-12-03 06:36:44 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-12-03 06:36:44 +0000 net-misc/openssh: allow stack protector on musl x86 + musl ppc See: b28378fc2358c24785f41fdf92c00d617998ea3d Bug: https://bugs.gentoo.org/706210 Signed-off-by: Sam James <sam@gentoo.org> net-misc/openssh/openssh-8.7_p1-r3.ebuild | 5 ----- net-misc/openssh/openssh-8.8_p1-r2.ebuild | 5 ----- net-misc/openssh/openssh-8.8_p1-r3.ebuild | 5 ----- 3 files changed, 15 deletions(-)
