Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 65002 - LDFLAGS in Gentoo
Summary: LDFLAGS in Gentoo
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
: 85931 114783 123791 138847 (view as bug list)
Depends on: 70367 77430
Blocks:
  Show dependency tree
 
Reported: 2004-09-22 11:32 UTC by aethyr
Modified: 2008-06-18 23:58 UTC (History)
22 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description aethyr 2004-09-22 11:32:51 UTC
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.
Comment 1 solar (RETIRED) gentoo-dev 2004-09-30 18:01:03 UTC
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.
Comment 2 aethyr 2004-09-30 19:14:51 UTC
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.
Comment 3 solar (RETIRED) gentoo-dev 2004-10-01 08:15:05 UTC
## 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.
Comment 4 gad.kadosh 2004-10-02 17:40:48 UTC
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.
Comment 5 Spider (RETIRED) gentoo-dev 2004-10-08 00:07:22 UTC
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.


Comment 6 Marc Vila 2004-10-08 00:11:22 UTC
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"
Comment 7 Peter S. Mazinger 2004-10-08 01:12:01 UTC
--enable-new-dtags is enabled in newer binutils by default
Comment 8 SpanKY gentoo-dev 2004-11-15 23:17:30 UTC
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
Comment 9 Heinrich Wendel (RETIRED) gentoo-dev 2004-12-29 10:35:19 UTC
so any chance to add this per default in gentoo 2005.0?
Comment 10 Patrick Kursawe (RETIRED) gentoo-dev 2005-01-07 06:02:28 UTC
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.
Comment 11 Danny van Dyk (RETIRED) gentoo-dev 2005-01-29 13:16:09 UTC
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?
Comment 12 Heinrich Wendel (RETIRED) gentoo-dev 2005-02-26 02:44:28 UTC
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)
Comment 13 SpanKY gentoo-dev 2005-03-22 08:28:30 UTC
*** Bug 85931 has been marked as a duplicate of this bug. ***
Comment 14 SpanKY gentoo-dev 2005-03-28 18:40:54 UTC
*** Bug 86986 has been marked as a duplicate of this bug. ***
Comment 15 Jakub Moc (RETIRED) gentoo-dev 2005-06-06 08:42:38 UTC
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. 
Comment 16 Jason Stubbs (RETIRED) gentoo-dev 2005-07-20 00:26:50 UTC
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.
Comment 17 Alexander Skwar 2005-09-29 13:28:23 UTC
(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.
Comment 18 Chris Bainbridge (RETIRED) gentoo-dev 2005-12-08 03:12:23 UTC
*** Bug 114783 has been marked as a duplicate of this bug. ***
Comment 19 Chris Bainbridge (RETIRED) gentoo-dev 2005-12-08 03:15:14 UTC
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?
Comment 20 Kevin F. Quinn (RETIRED) gentoo-dev 2005-12-08 04:09:28 UTC
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.
Comment 21 Mark Loeser (RETIRED) gentoo-dev 2005-12-15 14:16:45 UTC
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.
Comment 22 Joshua Kinard gentoo-dev 2005-12-24 21:50:55 UTC
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 :)
Comment 23 Chris Bainbridge (RETIRED) gentoo-dev 2006-02-23 06:19:45 UTC
*** Bug 123791 has been marked as a duplicate of this bug. ***
Comment 24 Chris Bainbridge (RETIRED) gentoo-dev 2006-07-02 12:13:38 UTC
*** Bug 138847 has been marked as a duplicate of this bug. ***
Comment 25 Jakub Moc (RETIRED) gentoo-dev 2007-04-14 16:07:34 UTC
*** Bug 174602 has been marked as a duplicate of this bug. ***
Comment 26 Steve L 2008-02-12 14:33:46 UTC
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.)
Comment 27 James Laver 2008-02-12 14:44:50 UTC
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.
Comment 28 SpanKY gentoo-dev 2008-02-13 18:48:21 UTC
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