| Summary: | sys-devel/gcc does not respect LDFLAGS | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | David J Cozatt <djcozatt> |
| Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | QA | CC: | esigra, mattst88, mgorny, nikoli, zerochaos, zlogene |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 454426 | ||
| Attachments: |
build.log
bzip2 of build.log toolchain.eclass.ldflags.diff toolchain.eclass.ldflags.diff toolchain.eclass.ldflags.diff |
||
|
Description
David J Cozatt
2010-09-17 11:32:33 UTC
Created attachment 247728 [details]
build.log
not built with FEATURES="test" iirc
A great build log indeed :P. Could you paste the 'package information' part of 'emerge --info gcc'? =================================================================
Package Settings
=================================================================
sys-devel/gcc-4.4.4-r2 was built with the following:
USE="fortran gtk mudflap (multilib) nls nptl openmp (-altivec) -bootstrap -build -doc (-fixed-point) -gcj -graphite (-hardened) (-libffi) -multislot (-n32) (-n64) -nocxx -nopie -nossp -objc -objc++ -objc-gc -test -vanilla"
(In reply to comment #2) > A great build log indeed :P. > > Could you paste the 'package information' part of 'emerge --info gcc'? > wrong log ;-( sorry but when I try to attach the right one it's too big david@random ~ $ ls -l /var/log/portage/sys-devel\:gcc-4.4.4-r2\:2010091* -rw-rw---- 1 portage portage 9839557 Sep 16 18:41 /var/log/portage/sys-devel:gcc-4.4.4-r2:20100916-210633.log -rw-rw---- 1 portage portage 9691633 Sep 19 15:48 /var/log/portage/sys-devel:gcc-4.4.4-r2:20100919-151146.log (In reply to comment #4) > wrong log ;-( sorry but when I try to attach the right one it's too big Nothing stops you from compressing it. Created attachment 248313 [details]
bzip2 of build.log
There is a 1000kb limit for files the bzip2 file is
ls -l sys-devel\:gcc-4.4.4-r2\:20100916-210633.log.bz2
-rw-rw---- 1 portage portage 204258 Sep 16 18:41 sys-devel:gcc-4.4.4-r2:20100916-210633.log.bz2
Ok, I'm pretty sure I see your LDFLAGS passed to the linker there... did you have similar problems with other application lately? Please paste the output of: \ $ readelf -d /usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.4/cc1 confirm this bug slep@mini ~ $ readelf -d /usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.4/cc1 Dynamic section at offset 0x82ada8 contains 23 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libmpfr.so.4] 0x0000000000000001 (NEEDED) Shared library: [libgmp.so.10] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000c (INIT) 0x403d70 0x000000000000000d (FINI) 0xa06aa8 0x0000000000000004 (HASH) 0x4002b0 0x000000006ffffef5 (GNU_HASH) 0x400928 0x0000000000000005 (STRTAB) 0x401f00 0x0000000000000006 (SYMTAB) 0x400af0 0x000000000000000a (STRSZ) 2269 (bytes) 0x000000000000000b (SYMENT) 24 (bytes) 0x0000000000000015 (DEBUG) 0x0 0x0000000000000003 (PLTGOT) 0xe2afe8 0x0000000000000002 (PLTRELSZ) 4560 (bytes) 0x0000000000000014 (PLTREL) RELA 0x0000000000000017 (JMPREL) 0x402ba0 0x0000000000000007 (RELA) 0x4029f0 0x0000000000000008 (RELASZ) 432 (bytes) 0x0000000000000009 (RELAENT) 24 (bytes) 0x000000006ffffffe (VERNEED) 0x402990 0x000000006fffffff (VERNEEDNUM) 1 0x000000006ffffff0 (VERSYM) 0x4027de 0x0000000000000000 (NULL) 0x0 slep@mini ~ $ emerge --info Portage 2.2_rc85 (default/linux/amd64/10.0/desktop/kde, gcc-4.4.4, glibc-2.12.1-r1, 2.6.35-gentoo-r5-1.04 x86_64) ================================================================= System uname: Linux-2.6.35-gentoo-r5-1.04-x86_64-Intel-R-_Atom-TM-_CPU_330_@_1.60GHz-with-gentoo-2.0.1 Timestamp of tree: Wed, 22 Sep 2010 03:15:01 +0000 app-shells/bash: 4.1_p7 dev-java/java-config: 2.1.11 dev-lang/python: 2.6.5-r3, 3.1.2-r4 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.3 sys-apps/sandbox: 2.3-r1 sys-devel/autoconf: 2.13, 2.67 sys-devel/automake: 1.6.3-r1, 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.4-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.35 (sys-kernel/linux-headers) ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=native -fomit-frame-pointer -mfpmath=sse+387 -mpc80 -msse3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=native -fomit-frame-pointer -mfpmath=sse+387 -mpc80 -msse3" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests buildpkg ccache distlocks fixlafiles fixpackages metadata-transfer news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch usersandbox usersync" GENTOO_MIRRORS="http://gentoo.tups.lv/source " LANG="ru_RU.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,--hash-style=gnu" LINGUAS="ru" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_COMPRESS="lzma" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/kde /home/slep/rion /home/slep/slepnoga/portage /var/lib/layman/sunrise" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X a52 aac aalib acl acpi akonadi alsa amd64 bash-completion berkdb bl bluetooth branding bzip2 cairo caps cdda cdio cdparanoia cdr cli clucene consolekit cracklib crypt cue cups cxx dbus dga djvu dri dts dvd dvdr emboss encode exif fam fbcon ffmpeg firefox flac fontconfig fortran ftp gdbm ggi gif gnutls gpm gstreamer hal handbook ical iconv icu idn imagemagick imlib inotify ipv6 jbig jpeg jpeg2k kde kerberos kvm ladspa lame lcms ldap libnotify libsamplerate lm_sensors log4j lzma lzo mad mikmod mmap mmx mmxext mng modplug modules mp3 mp4 mpeg mtp mudflap multilib multislot mysql ncurses nls nptl nptlonly nsplugin ogg opengl openmp optimized-qmake pam pango pch pcre pdf perl phonon pipe png pnm policykit ppds pppd python qt3support qt4 radio readline reflection rhelpatch rle samba sasl sdl semantic-desktop session sftp skype slp sms sndfile spell spice sql sqlite sse sse2 ssl ssse3 startup-notification strigi suexec svg symlink sysfs syslog taglib tcpd theora threads tiff truetype unicode usb vhosts vim-syntax vorbis wav wavpack webkit winetriks x264 xattr xcb xinetd xml xmlpatterns xorg xulrunner xv xvid xvmc zeroconf zip zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev" KERNEL="linux" LINGUAS="ru" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="intel" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS Ok, I see it now.. it seems that gcc compiles 'cc1' two times, not applying the flags the second time. referencing comment #11 would this apply across all gcc builds then? Yes, and it's simple to use user LDFLAGS here. I don't know if we want to. What I'd rather have is a var we can set to skip these warnings. Created attachment 259636 [details, diff]
toolchain.eclass.ldflags.diff
Purely theoretically, something like this would get us close. The only remaining files on my system are
* /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/32/libgcc_s.so.1
* /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/libgcc_s.so.1
I am not planning on looking into the reason they're omitted. I also haven't tested this with 2.* and 3.* or any languages past C and C++.
I'm not comfortable with someone being able to break their compiler with LDFLAGS. Maybe I'm being overcautious, I just haven't looked at the implications in detail and would expect anyone making this change to have done so.
> I'm not comfortable with someone being able to break their compiler with
> LDFLAGS. Maybe I'm being overcautious, I just haven't looked at the
> implications in detail and would expect anyone making this change to have
> done so.
This is unacceptable:
* QA Notice: Files built without respecting LDFLAGS have been detected
* Please include the following list of files in your report:
* /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libgomp.so.1.0.0
* /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libgcc_s.so.1
* /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libmudflapth.so.0.0.0
* /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libmudflap.so.0.0.0
* /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/32/libgomp.so.1.0.0
* /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/32/libgcc_s.so.1
* /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/32/libmudflapth.so.0.0.0
* /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/32/libmudflap.so.0.0.0
* /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/32/libstdc++.so.6.0.14
* /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libstdc++.so.6.0.14
* /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/collect2
* /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/cc1
* /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/lto-wrapper
* /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/cc1plus
* /usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3/x86_64-pc-linux-gnu-g++
* /usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3/x86_64-pc-linux-gnu-gcc
* /usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3/x86_64-pc-linux-gnu-gcov
* /usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3/x86_64-pc-linux-gnu-cpp
* /usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3/x86_64-pc-linux-gnu-c++
If you want to continue ignoring LDFLAGS it isn't my place to even attempt to make my case, however, not using QA_FLAGS_IGNORED in the ebuild will cause users to think you are so stupid you can't make gcc respect LDFLAGS... just my 0.02$
(In reply to comment #15) take it down a notch or two (In reply to comment #16) > (In reply to comment #15) > > take it down a notch or two I did not accuse anyone of anything. I said the build.log makes things appear to be accidently broken when it is clearly a conscious choice... I'm happy to QA fix this for all gcc versions in the tree if that makes my intentions more obvious but leaving it as is looks really bad. I am here to help people not berate them, if you re-read what I wrote I tried to keep that fact obvious. (Comment #13) > What I'd rather have is a var we can set to skip these warnings. (In reply to comment #15) > This is unacceptable: > > > * QA Notice: Files built without respecting LDFLAGS have been detected > * Please include the following list of files in your report: > * /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libgomp.so.1.0.0 > * /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libgcc_s.so.1 > * /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libmudflapth.so.0.0.0 > * /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libmudflap.so.0.0.0 > * /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/32/libgomp.so.1.0.0 > * /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/32/libgcc_s.so.1 > * /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/32/libmudflapth.so.0.0.0 > * /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/32/libmudflap.so.0.0.0 > * /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/32/libstdc++.so.6.0.14 > * /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libstdc++.so.6.0.14 > * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/collect2 > * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/cc1 > * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/lto-wrapper > * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/cc1plus > * /usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3/x86_64-pc-linux-gnu-g++ > * /usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3/x86_64-pc-linux-gnu-gcc > * /usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3/x86_64-pc-linux-gnu-gcov > * /usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3/x86_64-pc-linux-gnu-cpp > * /usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3/x86_64-pc-linux-gnu-c++ > > If you want to continue ignoring LDFLAGS it isn't my place to even attempt > to make my case, however, not using QA_FLAGS_IGNORED in the ebuild will Guess what didn't exist yet when I wrote the first comment. (In reply to comment #17) > I am here to help people not berate them, if you re-read what I wrote I > tried to keep that fact obvious. If my first reaction to your message is GFY then you're doing it wrong. :p > If my first reaction to your message is GFY then you're doing it wrong. :p
I apologize for the confusion, as I said my intent was not to insult anyone but to point out that the current state makes us all look bad as our own QA is telling us we are doing it wrong but instead of fixing it we leave it for years.
While I personally prefer to respect LDFLAGS, any solution the toolchain team agrees on (that makes the warnings go away) will be accepted. I offer my help in any way possible.
Thank you. Mike, what do you think about the patch I posted above for setting BOOT_LDFLAGS (for the stage 2 and 3 gcc build) and LDFLAGS_FOR_TARGET (for non-bootstrapped libs) versus setting QA_FLAGS_IGNORED. I don't care either way. *** Bug 450890 has been marked as a duplicate of this bug. *** Created attachment 347684 [details, diff]
toolchain.eclass.ldflags.diff
This should do the right thing from 3.4.6 up. I tested bootstrap and "make all" builds but not cross compiling (I could use some volunteers here). For bootstrapping we ignore flags for stage 1 like before, but later stages respect both CFLAGS and LDFLAGS now, as does building the target libs (think libgomp, libstdc++, etc). For cross-compiling there is of course only the one stage so we respect user flags for it. I wasn't sure if target libs should honour user flags for cross-compiling (do we want target libs built with host flags?) so I restricted it to bootstrapped builds.
libgcc_s.so.1 doesn't respect LDFLAGS at the moment but that's a one-line patch.
I noticed gcc_do_filter_flags() screws around with flags at the end too. The comments in there are ancient and not really accurate. That code should probably be merged into this (or this into that) but that's a cleanup for later.
What do you think sirs?
Created attachment 356166 [details, diff]
toolchain.eclass.ldflags.diff
*** Bug 486256 has been marked as a duplicate of this bug. *** (In reply to Ryan Hill from comment #23) > Created attachment 356166 [details, diff] [details, diff] > toolchain.eclass.ldflags.diff Time to commit this? Waiting on alpha to test it. Specifically that 4.7 fails to build on alpha without it and passes with. Oh, let me know that next time. :) I'll kick off some builds. Thanks, Ryan! We had to start filtering -frecord-gcc-switches due to bug #490738 so the QA part of this bug no longer applies and the alpha issues seem to have fixed themselves at some point. If there are actual problems caused by not propagating CFLAGS/LDFLAGS to each stage of the build then please open a new bug. |
