# Wie gefährlich/sinnvoll sind LDFLAGS?

## michel7

Ich habe bei mir mal einen Versuch gestartet und das gesamte System mit folgenden LDFLAGS neukompiliert (emerge -e world) ...

```

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

```

Muss vorerst sagen - es gab keinerlei Schwierigkeiten beim Neubauen des kompletten Systems. Das ganze hat zwar ca. 8 Stunden gedauert (insgesamt 492 Pakete) ... aber letztendlich war das Ergebnis positiv. Danach habe ich einfach eine Stoppuhr genommen und mir die Startzeiten von KDE und ein paar Anwendungen (wie Firefox, Thunderbird usw.) aufgeschrieben und dann mit den Ergebnissen, die ich davor (ohne LDFLAGS) notiert habe, vergliechen. Eigentlich müsste meiner Meinung nach zumindest KDE flotter laufen, da nur die tatsächlich benötigten lib's miteinkompiliert waren. Mein Fazit war recht enttäuschend - kein signifikanter/messbarer Unterschied! Also stellt sich die Frage ob die LDFLAGS überhaupt was nutzen, außer evtl. Stabilitätsprobleme?! Der einzige Unterschied, den ich feststellen konnte - war dass ich auf 3Gb Daten ca. 40MB Speicherplatz dazugewonnen habe (durch LDFLAGS). Anscheinend sind einige Binaries etwas kleiner geworden. Jetzt wollte ich wissen, wer welche Erfahrungen mit LDFLAGS gemacht hat?! Wie sinnvoll/gefährlich sind diese?

Hier noch ein paar Infos zu meinem System:

```
hades michel # emerge --info

Portage 2.1.2.7 (default-linux/x86/2007.0/desktop, gcc-4.1.2, glibc-2.5-r3, 2.6.21-gentoo-r2 i686)

=================================================================

System uname: 2.6.21-gentoo-r2 i686 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz

Gentoo Base System release 1.12.10

Timestamp of tree: Mon, 28 May 2007 07:30:01 +0000

dev-java/java-config: 1.3.7, 2.0.33

dev-lang/python:     2.4.4-r4

dev-python/pycrypto: 2.0.1-r5

sys-apps/sandbox:    1.2.18.1

sys-devel/autoconf:  2.13, 2.61

sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10

sys-devel/binutils:  2.17

sys-devel/gcc-config: 1.3.16

sys-devel/libtool:   1.5.23b

virtual/os-headers:  2.6.21

ACCEPT_KEYWORDS="x86 ~x86"

AUTOCLEAN="yes"

CBUILD="i686-pc-linux-gnu"

CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"

CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/revdep-rebuild /etc/terminfo"

CXXFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"

DISTDIR="/usr/portage/distfiles"

FEATURES="distlocks metadata-transfer parallel-fetch sandbox sfperms strict"

GENTOO_MIRRORS="http://distfiles.gentoo.org"

LINGUAS="en de ru"

MAKEOPTS="-j3"

PKGDIR="/usr/portage/packages"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

SYNC="rsync://rsync.gentoo.org/gentoo-portage"

USE="X a52 aac acl acpi alsa berkdb bitmap-fonts bluetooth bzip2 cairo cdda cddb cdr cli cracklib crypt css cups curl dbus dga divx djvu dts dvd dvdr dvdread eds emboss encode evo exif fam fbcon ffmpeg firefox flac fortran ftp gdbm gif glut gpm gps gstreamer gtk gtk2 hal hddtemp iconv icq ieee1394 imlib java javascript jpeg jpeg2k kde kdeenablefinal kdehiddenvisibility lesstif libg++ lzo mad md5sum midi mikmod mmx mmxext motif mp3 mpeg mplayer msn mudflap ncurses nls nptl nptlonly nsplugin nvidia ogg openal opengl openmp pam pcre pdf perl png pppd python qt3 qt3support quicktime rar readline real recode reflection reiserfs samba sdl seamonkey session sox spell spl sse sse-filters sse2 ssl svg tcpd theora threads tiff truetype truetype-fonts usb userlocales v4l v4l2 vcd vorbis wifi win32codecs wma wmf wxwindows x264 x86 xanim xcomposite xml xorg xpm xscreensaver xv xvid xvmc 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 mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en de ru" USERLAND="GNU" VIDEO_CARDS="nvidia"

Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY

```

----------

## schachti

Zur "Gefährlichkeit": Ich habe vor vielen Monaten/Jahren mal aus irgendeinem Thread im englischen Teil des Forums die Flags

```

LDFLAGS="-Wl,-O1"

```

übernommen, die dort als sicher eingestuft worden sind. Wie es mit den anderen aussieht, kann ich Dir leider nicht sagen.

Evtl. ist auch prelink etwas für Dich, das ist AFAIK auch als sicher angesehen.

----------

## SvenFischer

Ich habe diese am Start und habe glaube nur bei 1-2 Paketen Stress gehabt, dann nehme ich die sicheren LDFLAGS.

LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,now" <- Performance

#LDFLAGS="-Wl,-O1 -Wl,--sort-common"                                       <- sichere Einstellung

Leider habe ich die Vorteile nie gemessen und auch sonst keine Ahnung, was da im Detail wie funktioniert.

----------

## ichbinsisyphos

```
-Wl,--as-needed
```

 führt bei mir von zeit zu zeit dazu, dass pakete nicht kompilieren. kann man aber mit

```
 LDFLAGS="" emerge ...
```

 umgehen.

----------

## mv

 *michel7 wrote:*   

> 
> 
> ```
> LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--sort-common"
> ```
> ...

 

Das einzige Flag, das hier manchmal Ärger macht, ist -Wl,--as-needed, nämlich bei  *Quote:*   

> app-portage/deltup
> 
> app-text/sablotron
> 
> games-arcade/xgalaga
> ...

 

(sowie möglicherweise vlc, octave, grub, und das beryl-Zeug). Du kannst auch ohne Bedenken 

```
-Wl,--relax -Wl,-z,-combreloc
```

 aufnehmen (nur busybox und - merkwürdigerweise - glibc mögen -Wl,--relax nicht). Geschwindigkeitsmäßig betrachtet bringt das aber vermutlich alles praktisch nichts: Die Fragmentierung der Festplatte fällt da vermutlich sogar stärker ins Gewicht.

Aber die Optionen 

```
-Wl,-z,now
```

 würde ich nach Möglichkeit immer aufnehmen. Das kann zwar von der Geschwindigkeit betrachtet nur eher schaden, erhöht aber die Sicherheit Deines Systems - eine suid-Anwendung ohne diese Link-Optionen wurde sogar mal eine zeitlang von Portage als QA-Verletzung gemeldet (den genauen Grund dafür verstehe ich aber auch nicht; vermutlich hängt es damit zusammen, dass die Bibliotheksseiten beim ersten Laden vom Kernel gleich entsprechende Rechte zugewiesen bekommen, was beim "Lazy"-Linken wohl nicht passieren kann. Vielleicht könnte hier mal ein Kernel-Kundiger die Details erklären   :Question:  )

Vorsicht: xorg-server und -Treiber mögen -Wl,-z,now nicht.

Leider benötigt die -Wl,z,now-Optionen, dass die Bibliotheken mit -fPIC erstellt wurden, was leider nicht immer geschieht. Daher empfehle ich (trotz der Portage-Warnungen) -fPIC in den CFLAGS/CXXFLAGS. Man muss sich aber bei einigen Paketen darauf einstellen, dass die Compilation mit -fPIC fehlschlägt...

----------

## beejay

Ich finde es immer wieder amüsant, wie viel hier von Optimierungen erwartet wird. Um das Ganze mal auf ein allgemeinverständliches Beispiel zu führen: Nehmen wir an, Ihr habt einen Lamborghini mit 550PS. Nun entfernt Ihr die Lederbezüge von den Sitzen und fahrt nurnoch auf dem Drahtgestell sitzend. Was denkt Ihr, wie viel schneller das Auto dadurch wird?

Beispiel passt prima auf die heute üblicherweise durch die Hardware bereitgestellte potenzielle Rechenleistung. 

Also: lasst die Überoptimierung sein oder fräst euch auch gleich ein Fenster in Eure Rechner und klebt so einen Original VW-Polo-Arschgeweih-Sticker drauf, dann passt nämlich alles.

----------

## UTgamer

Ich selbst habe sie seit Jahren nicht mehr im Einsatz, hatte auf meinem alten Rechner zuviele Probleme mit ihnen. Aber das kann ich dir als Tips zum lesen mitgeben (da sind z.B. auch Programme aufgeführt die Probleme haben).

https://forums.gentoo.org/viewtopic.php?t=67777

http://gentoo-wiki.com/TIP_Safe_LDFLAGS

http://de.gentoo-wiki.com/LDFLAGS

http://lwn.net/Articles/192624/

Falls es nun weniger Probleme mit ihnen gibt, probiere ich sie evtl. ja auch wieder mal aus.  :Wink: 

----------

## ichbinsisyphos

 *beejay wrote:*   

> ...

 

solche meldungen solltest du dir sparen

----------

## beejay

 *ichbinsisyphos wrote:*   

>  *beejay wrote:*   ... 
> 
> solche meldungen solltest du dir sparen

 

Dann zeige Du mir doch bitte mal Dein Messprotokoll (oder sowas ähnliches), welches einen Zuwachs an Rechengeschwindigkeit mit 'getunten" Linker-Flags belegt.

Abgesehen davon dass ich glaube, dass nicht einmal 80% der Anwender die meinen soetwas benutzen zu müssen, weil sie mal irgendwo flüchtig was gelesen haben, überhaupt wissen was ein Linker ist.

----------

## ichbinsisyphos

 *beejay wrote:*   

>  *ichbinsisyphos wrote:*    *beejay wrote:*   ... 
> 
> solche meldungen solltest du dir sparen 
> 
> Dann zeige Du mir doch bitte mal Dein Messprotokoll (oder sowas ähnliches), welches einen Zuwachs an Rechengeschwindigkeit mit 'getunten" Linker-Flags belegt.
> ...

 

um was auch immer es geht, "würd ich nicht probiern", "gar nicht erst probiern", "ich würd aufgeben", "setz dich in diesen stuhl und warte aufs sterben" unterstrichen durch falsche analogien sind keine zulässigen antworten auf posts in einem forum im technologie- und informations-bereich.

sich mit solchen themen auseinanderzusetzen, auch wenn das ergebnis nach meinung mancher den aufwand nicht rechtfertigt, bringt was.

----------

## UTgamer

@beejay da muß ich ichbinsisyphos aber mal etwas recht geben. Eine Aussage wie "ist Scheiße, bringt nichts" etc, ist doch nicht gerade hilfreich ohne einen Grund zu nennen warum es nicht geht oder nichts bringt. Also ich hatte vor Jahren ja auch meine Erfahrungen gesammelt, fällt man auf die Schnauze hat man etwas gelernt.  :Wink: 

Ansonsten ist ja immer auch die Ungewißheit da, ich weiß nichts, ich sterbe dumm.   :Laughing: 

Evtl, sind ja einige Paramter hilfreich. Also ich gab ihm mal den Link zur lwn Beschreibung und auch zu den Progs die andere Tester als problematisch herausgefunden hatten. Mit viel Mühe könnte man ja einen goldenen Mittelweg finden. Mir wäre es zuviel Aufwand.  :Wink: 

----------

## Polynomial-C

 *mv wrote:*   

> (sowie möglicherweise vlc, octave, grub, und das beryl-Zeug)

 

Also beryl und vlc kompilieren mit --as-needed auf ~x86

So um mal noch etwas zur Frage des Ursprungsposters beizutragen, also -Wl,--as-needed möchte ich seit dem Updatedebakel mit expat nicht mehr missen. Wie bereits geschrieben wurde, kompiliert das eine oder andere Paket nicht mit --as-needed aber die Zahl solcher Pakete wird immer weniger.

Außerdem spart man sich so einiges an Kompilierzeit via revdep-rebuild dadurch  :Wink: 

P.S.: Angeblich funktioniert --as-needed erst mit >=sys-devel/binutils-2.17 zuverlässig. Ich kann mich leider nicht mehr erinnern, woher ich diese Information bezogen habe, aber vielleicht kann uns da ja mal jemand anderes drüber aufklären  :Wink: 

----------

## slick

Paßt denke ich besser ins Diskussionsforum. Verschoben.

----------

## schachti

 *Polynomial-C wrote:*   

> 
> 
> So um mal noch etwas zur Frage des Ursprungsposters beizutragen, also -Wl,--as-needed möchte ich seit dem Updatedebakel mit expat nicht mehr missen. Wie bereits geschrieben wurde, kompiliert das eine oder andere Paket nicht mit --as-needed aber die Zahl solcher Pakete wird immer weniger.
> 
> Außerdem spart man sich so einiges an Kompilierzeit via revdep-rebuild dadurch 
> ...

 

Ich oute mich und gestehe öffentlich ein, daß ich zu faul bin, 10 Seiten des englischen Threads durchzuwühlen, um rauszufinden, was -Wl,--as-needed jetzt damit zu tun hat - hättest Du evtl. einen direkten Link auf das konkret relevante Posting bzw. eine kurze Zusammenfassung?

----------

## Polynomial-C

Hi,

suche einfach nach den Posts von Gergan Penkov. Der hat das glaube ich erklärt. Aber ich kann ja mal versuchen es kurz zusammenzufassen, da ich jetzt auf die Schnelle dort auch keinen Beitrag gefunden habe, der das ausreichend erklärt.

Das Update von expat-1.95.8 auf expat-2.0.0 brachte haufenweise "error while loading shared libraries: libexpat.so.0: cannot open shared object file: No such file or directory" Fehlermeldungen in vielen Paketen (vor allem KDE) mit sich. Komischerweise linken unglaublich viele Pakete beim Kompilieren zur libexpat (vorausgesetzt man verwendet kein --as-needed als Option für den Linker), obwohl die meisten Programme auch ohne expat funktionieren würden - das Linken ist in diesem Fall vollkommen nutzlos und sorgt nur dafür, daß haufenweise Pakete neu kompiliert werden müssen, wenn sich an den libs von expat etwas ändert (so wie beim Sprug von Version <2.0.0 auf >=2.0.0), obwohl sie die libexpat gar nicht selbst nutzen. Hier setzt --as-needed an. Wenn man dem Linker diese Option übergibt, schaut dieser, ob das zu erstellende binary die libs zu denen es linkt auch wirklich benötigt. Falls ja, wird gelinkt, falls nein eben nicht.

All die Leute, die in diese expat-Updatefalle reingerasselt sind, hätten viel weniger Ärger damit gehabt, wenn deren System(e) mit --as-needed kompiliert worden wäre(n).

Und das Ganze braucht mal ja nicht nur für expat. Seitdem ich --as-needed in den LDFLAGS drin habe, findet revdep-rebuild auch viel seltener Sachen, die neu kompiliert werden müssen, einfach weil --as-needed dafür sorgt, daß die binaries nur zu den libs linken, die sie auch wirklich benötigen.

So, ich hoffe mal, daß ich jetzt hier keinen Lötzinn verzapft habe  :Wink: 

Falls jemandem Fehler in meiner Ausführung finden, bitte ich um Korrektur  :Wink:  Achja, ich hab' mich mit der Formulierung gerade ziemlich schwer getan. Also seid bitte nachsichtig, falls ihr nur Bahnhof versteht  :Wink: 

[edit]Tippfehler korrigiert[/edit]

----------

## moe

 *UTgamer wrote:*   

> @beejay da muß ich ichbinsisyphos aber mal etwas recht geben. Eine Aussage wie "ist Scheiße, bringt nichts" etc, ist doch nicht gerade hilfreich .. 

 

Das hat beejay ja auch nicht gesagt, sondern in einem recht anschaulichen Beispiel gesagt wie wenig es bringt. Im Übrigen teile ich seine Meinung 100%ig. Auf einem 286er kann mit Optimierungen aller Art bestimmt einiges rausholen, bei der heutigen Rechenleistung fällt das meist unter den Teppich, was ja auch die unzähligen "Ist Gentoo schneller als $foo" Diskussionen zeigen. Sicherlich schadet es nicht, und 40MB Gewinn von michel7 sind ja auch besser als nichts, aber wenn man sowas macht sollte man auch ansatzweise verstehen was man da macht, sonst sind Probleme sehr viel wahrscheinlicher als eine spürbare Verbesserung.

Um mal beim Autobeispiel zu bleiben, wenn du keine Ahnung von Motoren hast, überlässt du Optimierungen ja auch jemanden der sich damit auskennt, oder aber du lebst sehr gefährlich.

Gruss Maurice

----------

## TheSmallOne

 *Polynomial-C wrote:*   

> Hier setzt --as-needed an. Wenn man dem Linker diese Option übergibt, schaut dieser, ob das zu erstellende binary die libs zu denen es linkt auch wirklich benötigt. Falls ja, wird gelinkt, falls nein eben nicht.

 

Hm, das klingt für mich so, als sei es eine Option, die Programmierfehler ausbessert, die die Entwickler gemacht haben.

Zumindest scheint es mir, als sei "zu einer Bibliothek linken, die gar nicht benutzt wird" nicht anderes, als ein Fehler.

Gleichermaßen bringt mich das allerdings zu der Frage, wieso man diese Option überhaupt zusätzlich übergeben muß; ich finde es wäre die logische Verfahrensweise, nur das zu verlinken, was man auch braucht und somit sollte es das Standard-Verhalten sein, und höchstens eine Option existieren um es anders zu machen.

Gibt es irgendwelche Gründe für das gegenwärtige Standard-Verhalten?

----------

## Anarcho

Zum Thema "--as-needed":

http://www.gentoo.org/proj/en/qa/asneeded.xml

----------

## mv

 *beejay wrote:*   

> Dann zeige Du mir doch bitte mal Dein Messprotokoll (oder sowas ähnliches), welches einen Zuwachs an Rechengeschwindigkeit mit 'getunten" Linker-Flags belegt.

 

Offensichtlich hast Du zumindest mein Posting nicht gelesen: Mein Hauptpunkt ist der Zuwachs an Sicherheit (durch -Wl,-z,now). Da die Sache jetzt in das Diskussionsforum abgeschoben wurde, fürchte ich, wird meine Frage, inwiefern das richtig ist, unbeantwortet bleiben.

----------

## Fabiolla

 *mv wrote:*   

>  *beejay wrote:*   Dann zeige Du mir doch bitte mal Dein Messprotokoll (oder sowas ähnliches), welches einen Zuwachs an Rechengeschwindigkeit mit 'getunten" Linker-Flags belegt. 
> 
> Offensichtlich hast Du zumindest mein Posting nicht gelesen: Mein Hauptpunkt ist der Zuwachs an Sicherheit (durch -Wl,-z,now). Da die Sache jetzt in das Diskussionsforum abgeschoben wurde, fürchte ich, wird meine Frage, inwiefern das richtig ist, unbeantwortet bleiben.

 

Hallo, man ld gibt zu now folgendes aus:

```

now    When generating an executable or shared library, mark it to tell the dynamic linker  to  resolve

            all  symbols  when the program is started, or when the shared library is linked to using dlopen,

            instead of deferring function call resolution to the point when the function is first called.

```

lg

----------

## mv

 *Fabiolla wrote:*   

> 
> 
> ```
> now    When generating an executable or shared library, mark it to tell the dynamic linker  to  resolve
> 
> ...

 

Dieser Text ist mir bekannt, aber er ist ziemlich nichtssagend. Insbesondere klärt das nicht meine Frage, weshalb es (gemäß Gentoo QA) ein Sicherheitsrisiko ist, diese Option for SUID-Programme nicht zu benutzen.

Vor allem: Wenn es wirklich nur um den Zeitpunkt der Auflösung ginge, wie ich diesem Text zu entnehmen glaube, erklärt das absolut nicht, weshalb dies Ärger macht, wenn die Bibliothek nicht position-independent ist, und weshalb z.B. xorg-server mit dieser Option streikt.

Und überhaupt: Was ist der Unterschied zwischen dieser Option und der Variablen LD_BIND_NOW? "Überblendet" da das eine das andere?

----------

