Summary: | sys-devel/binutils-2.24: building some packages w/-Os can lead to: stack_chk_fail_local.c:(.text+0x10): undefined reference to __stack_chk_fail | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Philipp Riegger <bugs+gentoo> |
Component: | [OLD] Library | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ahferroin7, alexander, ap, endymion+gentoo, hardened, martin, mattmill30, maxtram95, mgorny, zerochaos |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
See Also: | https://bugzilla.redhat.com/show_bug.cgi?id=1028849 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 560792 | ||
Bug Blocks: | |||
Attachments: |
build log
emerge --info MM: emerge --info jfindlay: emerge --info |
Description
Philipp Riegger
2014-03-05 11:18:46 UTC
Attach the full build log please. Created attachment 371802 [details]
build log
CC'ing hardened for advice. Could it be related to https://bugzilla.redhat.com/show_bug.cgi?id=1028849 ? Does it work without --as-needed? LDFLAGS="-Wl,--no-as-needed" emerge -1v qtcore This works for me. Yeah, definitely looks like https://bugzilla.redhat.com/show_bug.cgi?id=1028849 Reassigning to toolchain. In the meantime, we certainly can add no-as-needed as a workaround in qtcore. Patches welcome. append-ldflags $(no-as-needed) from flag-o-matic. I don't have Hardened, so I can't test :). NAK. This bug is triggered only under a specific set of conditions (hardened + x86? hardened + -Os? hardened + something else?), and seems to affect only a small percentage of users, so appending --no-as-needed must be conditional as well. I'm not interested in disabling it for everyone. I don't use "hardened" profile but whith '--as-neeeded" I've triggerde the bug. (In reply to Vincent-Xavier JUMEL from comment #10) > I don't use "hardened" profile but whith '--as-neeeded" I've triggerde the > bug. post your emerge --info please Created attachment 390732 [details]
emerge --info
There you are !
(In reply to Vincent-Xavier JUMEL from comment #12) > Created attachment 390732 [details] > emerge --info > > There you are ! Interesting... you also use -Os, maybe that's triggering the bug. I'll try to reproduce with -Os locally. Ok, I can reproduce on non-hardened with ABI_X86=32 and CXXFLAGS=-Os, while -O2 works. x86_64-pc-linux-gnu-g++ -m32 -Wl,--hash-style=gnu -Wl,-O1 -Wl,--as-needed -Wl,-rpath-link,/tmp/portage/dev-qt/qtcore-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6-abi_x86_32.x86/lib -Wl,--no-undefined -shared -Wl,-Bsymbolic-functions -Wl,-soname,libQtXml.so.4 -o libQtXml.so.4.8.6 .obj/release-shared/qdom.o .obj/release-shared/qxml.o -L/tmp/portage/dev-qt/qtcore-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6-abi_x86_32.x86/lib -L/usr/lib32/qt4 -lQtCore -L/tmp/portage/dev-qt/qtcore-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6-abi_x86_32.x86/lib -lpthread /usr/lib32/libc_nonshared.a(stack_chk_fail_local.oS): In function `__stack_chk_fail_local': stack_chk_fail_local.c:(.text+0x10): undefined reference to `__stack_chk_fail' collect2: error: ld returned 1 exit status *** Bug 532192 has been marked as a duplicate of this bug. *** Created attachment 392296 [details]
MM: emerge --info
I have also encountered this issue.
For the time-being, would adding 'replace-flags -Os -O2' to the QtCore ebuild suffice, whilst a bug is lodged with GCC?
Before that though, it would be ideal to test applying -O2 to ./src/xml/Makefile alone, to see whether qdom.cpp or qxml.cpp is the only instance of QtCores -Os incompatiblity.
emerge --info attached
I have tested a compilation with LFLAGS=-lc manually entered into src/xml/Makefile, after configuration but before compilation. The build completes successfully, including the libQtXml. To patch the issue whilst it's investigated, is there an method using flags for when a build system is x86 and using CFLAGS="-Os" to make an ebuild sed -lc after LFLAGS in /src/xml/Makefile? Created attachment 395348 [details]
jfindlay: emerge --info
I've encountered this as well. My `emerge --info` is attached and here's the USE flags for qtcore: # equery uses dev-qt/qtcore [ Legend : U - final flag setting for installation] [ : I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for dev-qt/qtcore-4.8.6-r1: U I + + abi_x86_32 : 32-bit (x86) libraries - - debug : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see http://www.gentoo.org/proj/en/qa/backtraces.xml + - exceptions : Add support for exceptions - like catching them inside the event loop (recommended by upstream) + - glib : Enable dev-libs/glib eventloop support + + iconv : Enable support for the iconv character set conversion library - - icu : Enable ICU (Internationalization Components for Unicode) support, using dev-libs/icu + + qt3support : Enable the Qt3Support libraries for Qt4. Note that this does not mean you can compile pure Qt3 programs with Qt4. + + ssl : Add support for Secure Socket Layer connections any reason not to solve this bug with "replace-flags -Os -O2"? Even if this is a bug in the toolchain, I don't see why we need to leave the package unbuildable... (In reply to Rick Farina (Zero_Chaos) from comment #20) > any reason not to solve this bug with "replace-flags -Os -O2"? Even if this > is a bug in the toolchain, I don't see why we need to leave the package > unbuildable... No reason, I simply forgot about this... Would it be better to append --no-as-needed or to replace -Os with -O2 ? Also, is checking for "use x86 || use abi_x86_32" correct and enough? (In reply to Davide Pesavento from comment #21) > (In reply to Rick Farina (Zero_Chaos) from comment #20) > > any reason not to solve this bug with "replace-flags -Os -O2"? Even if this > > is a bug in the toolchain, I don't see why we need to leave the package > > unbuildable... > > No reason, I simply forgot about this... Would it be better to append > --no-as-needed or to replace -Os with -O2 ? > > Also, is checking for "use x86 || use abi_x86_32" correct and enough? I think removing as-needed is much worse than forcing -Os back down to a more common -O2 (and I use -Os exclusively on all arches, mostly to find awesome bugs like this). You can make it conditional like you suggest, or not. Seems we are mostly fixing a build error and the smallest change is the best one, so conditional seems appropriate. I have replicated this issue on both qtcore-4.8.5-r2 and qtcore-4.8.6-r1. Please fix both or nod and I'll apply the fix conditionally like you suggested. Workaround committed to both eclasses. Thanks. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/qt4-build.eclass?r1=1.161&r2=1.162 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/qt4-build-multilib.eclass?r1=1.7&r2=1.8 Probably a bug in binutils-2.24. See also bug 560438 Well, I can confirm my guess. I removed workaround from qt4 eclasses and successfully reproduced this bug with binutils-2.24-r3. Upgrade to binutils-2.25.1-r1 fixed it for me. *** Bug 560438 has been marked as a duplicate of this bug. *** *** Bug 534082 has been marked as a duplicate of this bug. *** *** Bug 528742 has been marked as a duplicate of this bug. *** Alexander Tsoy: thanks for double checking. we'll close this once arches finish stabilizing newer binutils in bug 560792. 2.25.1 is stable now, and we're not going to bother tracking down & backporting |