LDFLAGS Central

[Hasw]

Hm, I'm getting a Segmentation fault:

Code: Select all

hasw@hasw hasw $ LD_DEBUG=statistics sh -c true
     26096:     
     26096:     runtime linker statistics:
     26096:       total startup time in dynamic loader: 595306 clock cycles
     26096:                 time needed for relocation: 289777 clock cycles (48.6%)
Segmentation fault
hasw@hasw hasw $ 

sys-devel/binutils 2.15.92.0.2-r7
sys-libs/glibc 2.3.4.20041102-r1

[Bitspyer]

Hmmm I'm asking me, what is the better solution:

LDFLAG or prelink? Or both together???

[Dark_Cloud]

Hmmm I'm asking me, what is the better solution:

LDFLAG or prelink? Or both together???

you can use both.

[yardbird]

Hm, I'm getting a Segmentation fault:

Code: Select all

hasw@hasw hasw $ LD_DEBUG=statistics sh -c true
     26096:     
     26096:     runtime linker statistics:
     26096:       total startup time in dynamic loader: 595306 clock cycles
     26096:                 time needed for relocation: 289777 clock cycles (48.6%)
Segmentation fault
hasw@hasw hasw $ 

Same here... do you have custom LDFLAGS set in make.conf?

[teutzz]

Code: Select all

Teutzz teutzz # LD_DEBUG=statistics sh -c true
     17293:
     17293:     runtime linker statistics:
     17293:       total startup time in dynamic loader: 411310 clock cycles
     17293:                 time needed for relocation: 14399 clock cycles (3.5%)
     17293:                      number of relocations: 0
     17293:           number of relocations from cache: 21
     17293:             number of relative relocations: 0
     17293:                time needed to load objects: 236055 clock cycles (57.3%)
     17293:
     17293:     runtime linker statistics:
     17293:                final number of relocations: 65
     17293:     final number of relocations from cache: 21

and in my make.conf:

Code: Select all

Teutzz teutzz # cat /etc/make.conf | grep LDFLAGS
LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -s -Wl,--as-needed"

and the whole system is prelinked

[yardbird]

Hmm, I tried upgrading to binutils 2.16 but still the segfault... It's strange since I never had problems with binutils, I'd probably would have never discovered the issue if I had not seen this thread.

@Teutzz: I'm using your same LDFLAGS (apart from -as-needed), so I guess the problem is not there. Does anyone know what commands are executed when executing the LD_DEBUG="..." command?

[j-m]

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.

For emacs, you need only:

Code: Select all

LDFLAGS="-O1"

Probably the only package that does not interpret -Wl as an option passed to the linker.

[wel]

Anyone has tried something bigger than -O1? I mean, -O2 or -Os...

[taipan67]

Anyone has tried something bigger than -O1? I mean, -O2 or -Os...

As i understand other people's posts on the subject, & the 'ld' man-page, the -O optimisation-flag has only two states: zero or not-zero. So setting it to 1, 2, 3, or whatever won't make a blind bit of difference, as long as it's a number greater than zero. It's not the same principle as CFLAGS, so there won't be a size-option, either.

[Zentoo]

I've read this thread and i give you back my experience to have play a lot with my LDFLAGS this last year:

I've recompiled a whole system with this: LDFLAGS="-Wl,-O1"
At the first glaze no problem at all... But on the next reboot, system didn't finish to boot up.
It was looking for some libs on some partition that weren't yet mounted at boot.
It seems where is some problem with some library that are on /usr/*/lib and not on /lib that are required at boot.
It was enough a long time ago but i remember to have copy some library on /usr/*/lib without have mounted /usr
so no problem at boot time to look for them but i think it's a dirty hack...

So just be warned if you have a full separated partition scheme as i have about the use of LDFLAGS on a whole system.


Think about gpm libraries for reiserfs binaries was one of theses problems. ( i never understood the need of gpm for reiserfs !)

[j-m]

At the first glaze no problem at all... But on the next reboot, system didn't finish to boot up.
It was looking for some libs on some partition that weren't yet mounted at boot.
It seems where is some problem with some library that are on /usr/*/lib and not on /lib that are required at boot.

WTF?! How does the location where libraries are installed in the system depend on LDFLAGS

[MaratIK]

ld flag --relax conficts with -r, so they cannot use both.
Package where it occured is glibc-2.3.5.
It is strongly not recommended include -Wl,--relax into LDFLAGS

[MaratIK]

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?

ld is not the part of gcc, but binutils. Tips the same as is for previous versions of gcc.

[MaratIK]

My settings for LDFLAGS:

Code: Select all

LDFLAGS="-Wl,-O1,--sort-common,--enable-new-dtags,-zdynsort,-Bdirect,-hashvals"

Some explanation of last 3 settings can be found here

[vipernicus]

[*]--sort-common
This is to prevent gaps between symbols due to alignment constraints, presumably increasing efficiency layout.

Actually, it seems that it is the other way around.

-sort-common
Normally, when ld places the global common symbols
in the appropriate output sections, it sorts them
by size. First come all the one byte symbols, then
all the two bytes, then all the four bytes, and
then everything else. This is to prevent gaps be-
tween symbols due to alignment constraints. This
option disables that sorting.

[luminoso]

Code: Select all

$ LD_DEBUG=statistics sh -c true
     28385:
     28385:     runtime linker statistics:
     28385:       total startup time in dynamic loader: 1578708 clock cycles
     28385:                 time needed for relocation: 29708 clock cycles (1.8%)
     28385:                      number of relocations: 0
     28385:           number of relocations from cache: 29
     28385:             number of relative relocations: 0
     28385:                time needed to load objects: 1107048 clock cycles (70.1%)
     28385:
     28385:     runtime linker statistics:
     28385:                final number of relocations: 0
     28385:     final number of relocations from cache: 29

Code: Select all

grep LDFL /etc/make.conf
LDFLAGS="-Wl,-O1"

And no problems at all.
What should i care? time needed to load or time needed for relocation?

[Enlight]

[*]--sort-common
This is to prevent gaps between symbols due to alignment constraints, presumably increasing efficiency layout.

Actually, it seems that it is the other way around.

-sort-common
Normally, when ld places the global common symbols
in the appropriate output sections, it sorts them
by size. First come all the one byte symbols, then
all the two bytes, then all the four bytes, and
then everything else. This is to prevent gaps be-
tween symbols due to alignment constraints. This
option disables that sorting.

erm... no!

--sort-common
This option tells ld to sort the common symbols by size when it
places them in the appropriate output sections

other than this, /me still wonders why --enable-new-dtags has been removed from the original post.

edit : @zentoo, definitly not, you probably were using a statical prog and forgot about this.

[Dralnu]

Has anyone else messed with LDFLAGS in awhile? I'm going through and sorting out what might be nice and what might not be, and just want to know if there is any new news.



Edit: Um, have LDFLAGS been removed for some odd reason?

[wrc1944]

Mine are currently

Code: Select all

LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=both -Wl,-znow"

on several boxes.

I've been using these with the advanced Gentoo install method and overlay by nesl247 (previously know as Evolution Mission). Works great for me, and the the few packages that have problems with --as-needed or -znow can be taken care of by entries in an /etc/portage/bashrc.nesl247 file, as shown below.
---------------------------------------------------------------------------------------------------
# Packages in this array remove --as-needed.
as_needed_packages=(
${as_needed_packages[*]}
media-video/mjpegtools
kde-base/kdemultimedia
kde-base/kdemultimedia-kioslaves
net-mail/courier-imap
media-sound/cdparanoia
mail-client/evolution
media-libs/imlib
)

LDFLAGS="${LDFLAGS:-$( grep ^LDFLAGS /etc/make.conf | sed 's/LDFLAGS="//' | sed 's/"//')}"

for i in ${as_needed_packages[*]}
do
case ${CATEGORY}/${PN} in
${i})
LDFLAGS="$( echo ${LDFLAGS} | sed 's/-Wl,--as-needed//')"
break
;;
esac
done

# Packages in this array remove -znow.
znow_packages=(
${znow_packages[*]}
dev-python/gst-python
x11-base/xorg-server
x11-drivers/ati-drivers
)

for i in ${znow_packages[*]}
do
case ${CATEGORY}/${PN} in
${i})
LDFLAGS="$( echo ${LDFLAGS} | sed 's/-Wl,-znow//')"
break
;;
esac
done

export LDFLAGS=$( echo ${LDFLAGS} )

[Dralnu]

Ran into a problem. its -W, not 1, but a lower case L.

[wrc1944]

Correct. When you copy it from /etc/make.conf and paste it into the forum and add the code tags, the numeral one (1) and a lower case L really look almost identical. You have to look really close to see the numeral one has its top part at a slight downward angle, whereas the lower case L is horizontal.

[webdawg]

I had some ldflags that broke gst plugins. had to comment them out.

[ConiKost]

I am using atm this:

Code: Select all

LDFLAGS="-Wl,-O1 -Wl,-z,now -Wl,--as-needed -Wl,--enable-new-dtags -Wl,--sort-common -s"

works fine for me.

[enderandrew]

I am using atm this:

Code: Select all

LDFLAGS="-Wl,-O1 -Wl,-z,now -Wl,--as-needed -Wl,--enable-new-dtags -Wl,--sort-common -s"

works fine for me.

Don't forget --hash-style=both

And I'm working on a toolchain overlay that will add back in support for -Bdirect among many other things!

[gimpel]

Code: Select all

LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common"

on binutils-2.17.50.0.10 here.

No problems.