I'm not really sure how to best describe this, as I'm not really familiar with ld or linking, but I recently saw these two posts on the GNOME mailing list that made me wonder if we were missing out on some optimization opportunities: http://mail.gnome.org/archives/desktop-devel-list/2004-September/msg00377.html http://mail.gnome.org/archives/desktop-devel-list/2004-September/msg00381.html Note the second post from Jeff Waugh says that all of Ubuntu is built with these flags by default. I noticed in testing it out last week that for a binary distribution Ubuntu is pretty quick to start GNOME applications. I'd say possibly even faster than Gentoo, it's certainly one of the fastest binary distro's I've tried. Is this an no brainer optimization that we should be taking advantage of as well? I'm not sure where to file this bug exactly, so please move it if necessary. Reproducible: Always Steps to Reproduce: 1. 2. 3.
I'm not sure what your even filing a bug about here so I've got no idea where to redirect you. My two bits here is if you want to use LDFLAGS="-Wl,-O1" in your make.conf then go for it. Portage will export the variable and any autotools aware package should be able to take advantage of. I'm going to close this bug however as NEEDINFO. You can/should reopen it after you have gathered your thoughts and can explain exactly it is your wanting us to do.
Hi Solar, thanks for taking the time to respond. I have two thoughts as to what I would like to possibly see happen. 1) Addition of the ldflags to make.conf by default. This would give us a similar system as Ubuntu has (which also works on multiple architectures). I imagine you can contact their packaging maintainers for more details. Alternatively add them to make.conf, but leave commented out (with a comment above it, describing what it does, similar to CFLAGS). 2) Addition of a mention of ldflags to the handbook, just like we have cflags and cxxflags currently. Describe why someone might be interested in adding "-Wl,-O1" to their ldflags. Describe any potential drawbacks -- if there are any, I have not heard any yet. I'm waiting to hear back on an email I sent to Ulrich Drepper last week, asking if there would be any drawbacks. I don't have too much contact with Gentoo developers, but based on what other developers (both in and outside of Gentoo) have said, I think this is something that people might be interested in having. I'd like to raise awareness of people that this flag might be something that benefits their system.
## Linker Flags: # If level is a numeric values greater than zero ld optimizes the output. # This might take significantly longer and therefore probably should only be # enabled for the final binary. #LDFLAGS="-Wl,-O1" ----------------------------------------------------------------------------- Before jumping into adding this to make.conf can we get some real world stats? We also need to be provided with any drawbacks to using them on a global scale. granted we know it makes ld link time slower but should speedup program startup. But is that it? Does it mainly apply to position independent executables? Any gotchas? Who has done this on world and know that it's works as expedted? Last I knew KDE/QT had some problems respecting any LDFLAGS. (mixed results) Many packages have bad Makefile's which simply don't respect LDFLAGS so you also might need to use -Wl from CFLAGS.
Hi solar, aethyr... I've been following this bug for a bit. I have added in my make.conf some time ago the line: LDFLAGS="-Wl,-O1" my CFLAGS are unchanged: CFLAGS="-O2 -march=pentium4 -mcpu=pentium4 -pipe -fomit-frame-pointer -ftracer" (gcc 3.3) The system is generally x86 keywords. I have not recompiled world, but I did recompile quite some apps, such as xchat, gaim, nautilus, firefox, rhythmbox, totem (and all portage updates since then), and I do feel that there's a noticable faster startup time for apps. By the way, I don't use pre-linking and never did. I think this issue should be considered seriously and checked to see if it's possible to better integrate it in gentoo, like aethyr says.
My system is actually built as CFLAGS="-O2 -march=athlon-xp -pipe" LDFLAGS="-Wl,-O1" CXXFLAGS="${CFLAGS}" FEATURES="nostrip" And I can ascertain that it doesn't carry any ill effects that I can note. Also, its not increasing the linking that much really. I think this -could- actually be a placebo effect though, check the binutils default values of optimize in various places. I was looking at fex. combreloc, when I realized that its already enabled by default.
I also added some ldflags in my computer some weeks ago, and didn't have any problem when compiling. I also think this should be considered: LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -s" As you see I added a little bit longer LDFLAGS, but seem pretty stable. I guess that we should only use the totally safe ldflags, that won't break any packages. My emerge info: Portage 2.0.51_rc7 (gcc34-x86-2004.2, gcc-3.4.2, glibc-2.3.4.20040808-r0, 2.6.9-rc3-nitro1 i686) ================================================================= System uname: 2.6.9-rc3-nitro1 i686 Intel(R) Pentium(R) M processor 1500MHz ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.92.0.2 Headers: sys-kernel/linux26-headers-2.6.8.1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=pentium-m -mtune=pentium-m -pipe -ftracer -fomit-frame-pointer -ffast-math -momit-leaf-frame-pointers" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=pentium-m -mtune=pentium-m -pipe -ftracer -fomit-frame-pointer -ffast-math -momit-leaf-frame-pointers -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs buildpkg ccache distlocks sandbox" GENTOO_MIRRORS="http://www.ibiblio.org/pub/Linux/distributions/gentoo http://ftp.caliu.info/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X aalib alsa apm avi berkdb bitmap-fonts divx4linux dvd encode fbcon foomaticdb gdbm ggi gif gpm gtk gtk2 i8x0 imlib javascript jpeg libg++ libwww mad mikmod mmx motif mpeg ncurses nothemes nptl oggvorbis opengl pam pdflib perl png python quicktime readline sdl slang sse sse2 ssl svga tcltk tcpd tiff truetype x86 xml xml2 xmms xprint xv xvid zlib"
--enable-new-dtags is enabled in newer binutils by default
before we hop into this we need to straighten out LDFLAGS LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common" these, for example, are not linker flags per-say ... those are really gcc flags which pass on to ld 'proper' LDFLAGS in this case would be: LDFLAGS="-O1 --enable-new-dtags --sort-common" the issue is that a lot of packages dont do LDFLAGS right ... they often times group CFLAGS and LDFLAGS together that means the current/safest way to get these into portage is to add them onto CFLAGS via the -Wl, pass-through mech i'd suggest we put off LDFLAGS for now until we can get some mad QA on our packages and have people do reasearch into how to properly get LDFLAGS into most packages out there
so any chance to add this per default in gentoo 2005.0?
It seems most packages use LDFLAGS as an addition to CFLAGS when gcc is called to link the final target - not in direct calls to ld. I just ran into this problem since emacs-21.3-r3 is the first exception I have met which tries to call ld with my "-Wl..." and fails therefore.
Adding CFLAGS="-Wl,<*>" will break most packages that supply shared objects on amd64. configure tests for -fPIC with full CFLAGS and listens for any warning. "-Wl,<*>" will cause gcc to spit out: x86_64-pc-linux-gnu-gcc: <*>: linker input file unused because linking not done and configure thinks: Hey, we can't do -fPIC here. Nasty, isn't it?
CFLAGS="-Wl,-O1" fails on amd64 that's right, but I had no problems (except emacs) with LDFLAGS="-Wl,-O1" so I think we can make this default (as ubuntu does as well)
*** Bug 85931 has been marked as a duplicate of this bug. ***
*** Bug 86986 has been marked as a duplicate of this bug. ***
I recompiled my whole testbox (gcc-3.4.4, glibc-2.3.5-r0) recently with CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" CXXFLAGS="${CFLAGS}" LDFLAGS="-Wl,-O1" and it worked without a hitch, not a single problem.
Same as Jakub's and Spider's here too on both athlon-xp and opteron. No problems at all. The issues that crop up with putting LDFLAGS into CFLAGS, however, happen on x86 too.
(In reply to comment #15) > I recompiled my whole testbox (gcc-3.4.4, glibc-2.3.5-r0) recently with > > CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" > CXXFLAGS="${CFLAGS}" > LDFLAGS="-Wl,-O1" > > and it worked without a hitch, not a single problem. Can you try to compile findutils-4.2.24, please? See bug #107638.
*** Bug 114783 has been marked as a duplicate of this bug. ***
So, is LDFLAGS supposed to support the gcc -Wl,x syntax or actual ld options? Are packages supposed to be using gcc only to link, and never ld directly?
My understanding is that LDFLAGS is an autotools convention, to be supplied to invocations of AC_PROG_CC (i.e. gcc for our purposes) not ld, since autotools uses AC_PROG_CC to link. Similarly libtool passes flags to the linker via the '-Wl,foo' or '-Xlinker foo' syntax. I think if we find anything expanding LDFLAGS on a specific ld invocation, we should change the name of the variable in the build -or perhaps better, change the build to use the compiler instead of ld.
Just my 2 cents...I have never had a problem with: LDFLAGS="-Wl,-O1 -Wl,--sort-common" I'm not sure what we are trying to establish here. That we support certain sets of LDFLAGS? I think most packages Just Work, if you use them like I do. We can only reall tackle this on a case by case basis when users start to use them.
LDFLAGS was added to portage (same as ASFLAGS) _only_ as a utility for specific, special-need cases where a program needs to be force-fed some kind of linker/assembler flag to compile properly. Generally, passing flags to 'ld' or 'as' via -Wl,-xxx or -Wa,-xxx works as a supplement (in C[XX]FLAGS). Using these to try and squeeze extra optimization out is only for the brave, and I do not think we'll ever see them listed in make.conf.example/Handbook because too many users would likely abuse them and start filing bugs with us (-Wl,-omg-more-more-more). If you use either form, do so knowing the risks, and any broken systems/bugs filed and discovered to be linked to these will probably get marked invalid :)
*** Bug 123791 has been marked as a duplicate of this bug. ***
*** Bug 138847 has been marked as a duplicate of this bug. ***
*** Bug 174602 has been marked as a duplicate of this bug. ***
According to http://bugs.gentoo.org/show_bug.cgi?id=77430#c13 "LDFLAGS are passed directly through the linker. This is why -Wl, is not recognized. The proper way to fix this is to set LDFLAGS=$(raw-ldflags) (the function is defined in flag-o-matic." And we have: comment #20 > My understanding is that LDFLAGS is an autotools convention, to be supplied to > invocations of AC_PROG_CC (i.e. gcc for our purposes) not ld, since autotools > uses AC_PROG_CC to link. Similarly libtool passes flags to the linker via the > '-Wl,foo' or '-Xlinker foo' syntax. > > I think if we find anything expanding LDFLAGS on a specific ld invocation, we > should change the name of the variable in the build -or perhaps better, change > the build to use the compiler instead of ld. > Another variable to handle flags directly for ld (since the convention has been established via autotools/gcc already) would just be the value of be $(raw-ldflags) afaict. Can we do that via appending current LDFLAGS to CFLAGS and then using $(raw-ldflags) somewhere else? (ie not LDFLAGS since that would break the CFLAGS setting via autotools, afaict; sorry if I'm misreading.)
This is a problem with a number of packages (particularly old ones with AWOL maintainers), not with the way LDFLAGS works. LDFLAGS is meant to be raw and passed to ld, not in the right format for gcc to pass. So the problem per se is not the LDFLAGS variable, but a subset of the portage tree.
no, LDFLAGS in the autotools concept is supposed to be passed to the compiler driver ... that means you need -Wl,-flag any package that invokes LDFLAGS directly needs to utilize the raw-ldflags func: export LDFLAGS=$(raw-ldflags) or even better: dont invoke ld directly packages which dont respect LDFLAGS should be fixed
