LDFLAGS Central

Message

taviso · Post by **taviso** » Wed Jul 16, 2003 4:28 pm

You may or may not be aware that the next versions of portage will probably support $ASFLAGS and $LDFLAGS, options that are usually passed to the assembler and linker during the build process.

There are even patches on gentoo-dev to add this support, although you can still use $LDFLAGS and $ASFLAGS without this patch, just by setting them in /etc/make.conf.

http://marc.theaimsgroup.com/?l=gentoo- ... 425320&w=2

$ASFLAGS is not particularly useful, it will probably be supported only for completeness. $LDFLAGS, however, could be useful and I have been experimenting recently to see what exactly can be done with them.

First of all, you can benchmark dynamic linking using the $LD_DEBUG variable, for example:

Code: Select all

taviso@insomniac:~$ LD_DEBUG=statistics sh -c true
12937:  
12937:  runtime linker statistics:
12937:    total startup time in dynamic loader: 1108348 clock cycles
12937:              time needed for relocation: 572272 clock cycles (51.6%)
12937:                   number of relocations: 132
12937:        number of relocations from cache: 5
12937:             time needed to load objects: 335136 clock cycles (30.2%)
12937:  
12937:  runtime linker statistics:
12937:             final number of relocations: 204
12937:  final number of relocations from cache: 5

as you can see, you can get the dynamic loader to print out lots of interesting stats, mostly measured in clock cycles.

These are some of the ld options that look interesting:

-O level
If level is a numeric values greater than zero ld optimizes the output.
--sort-common
This is to prevent gaps between symbols due to alignment constraints, presumably increasing efficiency layout.
--no-keep-memory
This option tells ld to optimize for memory usage rather than speed, by rereading the symbol tables as necessary instead of caching it in memory.
-z now
Lazy binding is really clever, rather than loading all shared code into memory at runtime, the dynamic loader locates them, and just keeps track of it, when a reference is made to the shared code, then it is loaded memory. This saves some memory, and speeds up startup. Using -z now disables lazy binding, which means slower startup, possibly more memory usage, but better runtime performance.
You can test how this will effect a particular application by setting $LD_BIND_NOW, and testing responsiveness or timing some task, for example:
Code: Select all
```
taviso@insomniac:~$ LD_BIND_NOW=1 mozilla
```

I Should also point out that when gcc is used to indirectly call ld, it wont always pass the $LDFLAGS to the linker, to force it to you must use the -Wl switch, all spaces in the switch must be substituted with commas. These are my $LDFLAGS, to demonstrate:

Code: Select all

LDFLAGS="-Wl,-O1 -Wl,--sort-common -s"

References I used to collect this information, you can read these for more information:

ld(1) manpage
ld.so(8 ) manpage
http://www.caldera.com/developers/gabi/ ... namic.html
latest ELF draft, Dynamic linking section
http://sources.redhat.com/binutils/docs ... ml#Scripts
linker scripts description
proc(5) manpage

note: this post is 2 years old, i've made a few updates to reflect that.

aardvark · Post by **aardvark** » Wed Jul 16, 2003 5:01 pm

I don't quite understand your line here. One would not expect a "," between -z and combreloc.

Code: Select all

LDFLAGS="-Wl,-z,combreloc -Wl,-O,2 -Wl,--relax -Wl,--enable-new-dtags -Wl,--sort-common -s"

Furthermore I am pretty sure that at some point in gentoo history , with certain binutils and glibc, " -z combreloc " is enabled by default when U emerge something in portage. (Just default for the compiler)

You can see that it is enabled (this is when it was introduced) by:

Code: Select all

bash-2.05b$ LD_DEBUG=statistics konqueror
04646:
04646:  runtime linker statistics:
04646:    total startup time in dynamic loader: 1595176706 clock cycles
04646:              time needed for relocation: 1044423406 clock cycles (65.4%)
04646:                   number of relocations: 29638
04646:        number of relocations from cache: 54945
04646:             time needed to load objects: 550219972 clock cycles (34.4%)
mcop warning: user defined signal handler found for SIG_PIPE, overriding
ASSERT: "m_widget" in kaction.cpp (2993)
04646:
04646:  runtime linker statistics:
04646:             final number of relocations: 47460
04646:  final number of relocations from cache: 109400

The cached relocations indicate that it is enabled. before combreloc there where no cahced relocation. Do you have some proof that it helps to enable it in your LDFLAGS explicitly?

taviso · Post by **taviso** » Wed Jul 16, 2003 5:16 pm

aardvark wrote:I don't quite understand your line here. One would not expect a "," between -z and combreloc.

The comma is correct, it is stripped out by gcc when it calls the linker.

Furthermore I am pretty sure that at some point in gentoo history , with certain binutils and glibc, " -z combreloc " is enabled by default when U emerge something in portage. (Just default for the compiler)

Not as far as i am aware.

aardvark · Post by **aardvark** » Wed Jul 16, 2003 5:37 pm

Ok, but would

Code: Select all

LDFLAGS="-z combreloc"

work?
(I only want combreloc, that I still think I already have anyway

)

taviso · Post by **taviso** » Wed Jul 16, 2003 5:47 pm

aardvark wrote:Ok, but would
Code: Select all
LDFLAGS="-z combreloc" 
work?

yep, -z xxx is really the exception to the rule, gcc understands that its always a linker invocation option. I only used it with -Wl for consistency. The guide was only a reference, i thought maybe some other people who like to tinker would enjoy it.

(I only want combreloc, that I still think I already have anyway )

incidentally, combreloc is the default linker script in recent versions of ld.

aardvark · Post by **aardvark** » Sun Jul 20, 2003 7:37 am

taviso wrote:[
incidentally, combreloc is the default linker script in recent versions of [url=http://sources.redhat.com/cgi-bin/cvswe ... og?cvsroot
=src]ld[/url].

And that means that it is enabled on my system already?

deadbeef · Post by **deadbeef** » Fri Nov 14, 2003 4:01 pm

I have to rebuild my system tomorrow, I'm going to try this out.

I'll do some benchmarks before+after & post back any results.

-0xdb

pennedinil · Post by **pennedinil** » Sat Oct 09, 2004 5:14 am

For completeness, should the flags not be

Code: Select all

LDFLAGS="-Wl,-O1 -Wl,--relax -Wl,--enable-new-dtags -Wl,--sort-common -Wl,-s"

Hackeron · Post by **Hackeron** » Fri Oct 15, 2004 10:48 pm

breaks emacs compile! -- everything else so far compiles just fine, but emacs says:

Code: Select all

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/ld: unrecognized option '-Wl,-O1'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/ld: use the --help option for usage information
collect2: ld returned 1 exit status
make[1]: *** [temacs] Error 1

dalek · Post by **dalek** » Wed Jan 19, 2005 11:14 am

This is my ldflags.

Code: Select all

LDFLAGS="-Wl,-O1"

I read that in another thread somewhere on here. Is that safe? Does it help any? Is there a better setting for my rig? Are they rig specific? I'm not a guru regardless of what is under my name over there.

Hmmm. Now it says l33t. Wonder when that changed.

AMD 2500+ CPU and 1GB of ram. I like speed, I am using Gentoo

, but I also want stability. I am almost to 70 days uptime. Woooo Ooooo.

Thanks.

taskara · Post by **taskara** » Wed Jan 19, 2005 11:36 am

LDFLAGS are not hardware specific afaik.

So they will work on any system.

The initial post from 2003 suggests

Code: Select all

LDFLAGS="-Wl,-O1 -Wl,--relax -Wl,--enable-new-dtags -Wl,--sort-common -s"

but --relax is only for alpha, and --enable-new-dtags is the default for current binutils, and -s is not neccessary afaik because gentoo strips all packages by default.

so the only other thing you could try is

Code: Select all

LDFLAGS="-Wl,-O1 -Wl,--sort-common"

wrc1944 · Post by **wrc1944** » Wed Jan 19, 2005 8:46 pm

After much thought, and a lot of reading, I just put

LDFLAGS="-Wl,-O1"

in my make.conf, and started an emerge -e system. I'm cruising along at 21 out of 103 to go, but am not seeing any LDFLAGS related stuff in the gcc output.

What output am I supposed to be looking for, and does it even show up in the output, like the CFLAGS do? In other words, how do I know if I'm really compiling with the LDFLAGS I set in .make.conf?

One more thing: I know it's -Wl (letter L, not numeric 1), but can't find anything regarding if -o1 is -o(letter o), or -0(numerical zero). Since I didn't know which, I pasted what was in the LDFLAGS post, and it seems to be working (shows up in emerge --info), but since I'm not seeing any LDFLAGS output I can identify, I'm still wondering if I have it correct.

Thanks,
wrc1944

SoTired · Post by **SoTired** » Wed Jan 19, 2005 10:27 pm

The ldflags will only show up during an emerge during linking, which generally is very quick/easy to miss. If you watch an emerge and it gets to a point where you see a lot of .o files on one line, there should be ldflags there as well.

The 'O' is a capital letter o, just like O for gcc (cflags) they both turn on optimizations.

As reference, an example from my current compilation of gtk+:

/bin/sh ../libtool --mode=link i586-pc-linux-gnu-gcc -pipe -Os -march=pentium -
mieee-fp -momit-leaf-frame-pointer -fforce-addr -freorder-blocks -fomit-frame-po
inter -fmove-all-movables -fmerge-all-constants -ftracer -finline-functions -fwe
b -frename-registers -fpeel-loops -fstack-protector -ffast-math -Wall -Wl,--ena
ble-new-dtags -Wl,--sort-common -s -o testtreesort testtreesort.o ../gdk-pixbuf
/libgdk_pixbuf-2.0.la ../gdk/libgdk-x11-2.0.la ../gtk/libgtk-x11-2.0.la
i586-pc-linux-gnu-gcc -pipe -Os -march=pentium -mieee-fp -momit-leaf-frame-point
er -fforce-addr -freorder-blocks -fomit-frame-pointer -fmove-all-movables -fmerg
e-all-constants -ftracer -finline-functions -fweb -frename-registers -fpeel-loop
s -fstack-protector -ffast-math -Wall -Wl,--enable-new-dtags -Wl,--sort-common -
s -o .libs/testtreesort testtreesort.o ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so

Note the "-Wl,--enable-new-dtags -Wl,--sort-common".

taipan67 · Post by **taipan67** » Thu Jan 20, 2005 9:19 pm

When did '-z combreloc' get edited out of the original post, & why?

I ask because i've just started a very careful rebuild, & had to remove it from my LDFLAGS to get 'glibc' to compile (it's doing so now - i hope it finishes okay...

)

taipan67 · Post by **taipan67** » Thu Jan 20, 2005 10:02 pm

taipan67 wrote:When did '-z combreloc' get edited out of the original post, & why?

I ask because i've just started a very careful rebuild, & had to remove it from my LDFLAGS to get 'glibc' to compile (it's doing so now - i hope it finishes okay... )

Further to my previous post, because i'm using the 'nptl' USE-flag by itself, & not with the 'nptlonly' one, glibc gets built twice - once without nptl-support, & again with.

By chance, i happened to be watching the text scroll by when the second part of the build started, & noticed that the check for '-z combreloc' returned 'yes', whereas it returned 'no' on the first part (without nptl-support).

I'm not about to do another restart of the entire process to check this out, but i am surmising that an 'nptlonly' system wouldn't spit the '-z combreloc' LDFLAG back in my face. I don't think Gentoo's quite ready to be nptlonly, but i would like any guidance that might be available on whether or not i can put '-z combreloc' back in my LDFLAGS once glibc has finished compiling...

taviso · Post by **taviso** » Thu Jan 20, 2005 10:58 pm

taipan67 wrote:i would like any guidance that might be available on whether or not i can put '-z combreloc' back in my LDFLAGS once glibc has finished compiling...

combreloc has been the default linker script for a while now, you dont need it.

taipan67 · Post by **taipan67** » Thu Jan 20, 2005 11:13 pm

taviso wrote: combreloc has been the default linker script for a while now, you dont need it.

Thanks for the reassurance - currently ploughing through gcc-3.4.3-compile without '-z combreloc'...

wrc1944 · Post by **wrc1944** » Thu Jan 20, 2005 11:45 pm

SoTired,
Thanks for the info. I got most of the way through emerge -e system, and came back in and my computer was off. Apparently my power supply failed, so I ordered a new 580 watt monster, and presently am back to my old mandrake backup box for a few days, so I can't see how these LDFLAGS work.. Haven't used this older box in about 3 months, and even though it has Mandrake 10.1 on it (just did it today), I'm now reminded of why I went to Gentoo Almost two years ago.

depontius · Post by **depontius** » Thu Mar 10, 2005 5:02 pm

Is there a way to get LDFLAGS tailored differently for a specific package, kind of like /etc/portage/package.use?

For most software the suggestions in this thread are good, but XOrg seems to think differently. (IIRC they mentioned security concerns) It will build with these flags, but complains every time and makes suggestions, though at the moment the only one I can remember is "-z now". For that matter, XOrg already strips a bunch of CFLAGS, maybe it a package has feelings that strong, they should strip and rework LDFLAGS, too.

wrc1944 · Post by **wrc1944** » Thu Mar 10, 2005 6:08 pm

Update:
I guess sometimes packages do strip LDFLAGS. I've been using the basic

LDFLAGS="-Wl,-O1"

for about three weeks now. In addition to a few emerge syncs and -upD worlds, I've also done an emerge -e system, and an emerge -e world during this time, with no problems, on two ~x86 systems with gcc-3.4.3-20050110. I've noticed the LDFLAGS showing up in the gcc output of some packages, but not in others.

I've had no issues so far, and no complaints.

Kyrra · Post by **Kyrra** » Sun Apr 03, 2005 5:28 pm

I had the same problem with using LDFLAGS to compile Emacs as listed in a post higher in this thread. But everything else I've compiled on my system hasn't had a problem with the LDFLAGS yet.

dalek · Post by **dalek** » Sun Apr 03, 2005 11:57 pm

I was using this but was getting a error about lazy bindings: edit, notice that this line is commented out.

Code: Select all

#LDFLAGS="-Wl,-O1"

I then changed back to this:

Code: Select all

LDFLAGS='-Wl,-z,now'

I have not had any of those errors that I can see anyway.

Rig in sig if that matters. New one seems faster but not real sure though.

Later

infirit · Post by **infirit** » Fri Apr 08, 2005 8:38 pm

Another flag that I am looking into lately is -Wl,--as-needed. Some app break horibly but most benefit from it .

It all started with an editorial on osnews.com and this thread is a result of it.

makzu · Post by **makzu** » Sat Apr 23, 2005 7:56 am

I'm looking around the man page for ld right now, wondering what else we can add into this. (Yes, I am a ricer, I have to make sure I'm not missing anything) Anyway, there's a few options that I'm a little curious about now, including:

--strip-debug
Omit debugger symbol information (but not all symbols) from the
output file.

Debug information really isn't something that we need anyway, is it?

--relax
An option with machine dependent effects. This option is only sup-
ported on a few targets.

On some platforms, the --relax option performs global optimizations
that become possible when the linker resolves addressing in the
program, such as relaxing address modes and synthesizing new
instructions in the output object file.

On some platforms these link time global optimizations may make
symbolic debugging of the resulting executable impossible. This is
known to be the case for the Matsushita MN10200 and MN10300 family
of processors.

On platforms where this is not supported, --relax is accepted, but
ignored.

Does this do anything at all on an x86 or amd64 machine?

Also, is --enable-new-dtags useful any more?

schrepfler · Post by **schrepfler** » Tue May 31, 2005 9:31 pm

Are there any new tips for the use of LDFLAGS, what are some good configs for the 3.4, 3.4 and 4.0 compilers?

LDFLAGS Central

LDFLAGS Central

per-package LDFLAGS