Hallo Steffen, Steffen Dettmer wrote:

* Boris Höffgen wrote on Tue, Dec 20, 2005 at 20:23 +0100:

...

--prefix=/usr/local/gcc/4.0.2

...

Verwende ich den Compiler, kompiliert er auch mein Programm, aber er bricht beim Start des Programms mit folgender Meldung ab:

(er == wer? ld-linux.so?)

ok, er ist der neue Compiler, z.B. gcc der Version 4.0.2

...

error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

Wo liegt der Fehler?

<geraten> /usr/local/gcc/4.0.2/lib (oder was da ist) mit libstdc++.so.6 nicht im /etc/ld.so.conf eingetragen? ldconfig -v danach nicht vergessen.

Ich habe den Pfad nicht in der ld.so.conf eingetragen. Kann ich das umgehen ohne als static zu kompilieren?

Sonst -static (statisch linken) oder auch LD_PRELOAD=/usr/local/gcc/4.0.2/lib/liblstdc++.so.6 ./myprog falls Du ld.so.conf nicht mit dem Zweitlibs belasten willst. </geraten>

Hat's geholfen?

Jepp. Danke Gruß Boris

* Thomas Hertweck wrote on Tue, Dec 20, 2005 at 21:52 +0000:

Siehe auch "man 8 ld.so" fuer Details.

ich hab hier: http://www.selflinux.org/selflinux/html/bibliotheken03.html mal was dazu geschrieben. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.

Hallo, Am Thu, 22 Dec 2005, Thomas Hertweck schrieb:

Steffen Dettmer wrote:

...

[...] ich hab hier: http://www.selflinux.org/selflinux/html/bibliotheken03.html mal was dazu geschrieben.

Hab's mal kurz ueberflogen: liest sich gut! Zwei kurze Anmerkungen:

- Du schreibst, rpm sei statisch gelinkt, was aber IMO (zumindest hier bei mir) nicht richtig ist:

$ file /SUSE91/bin/rpm /bin/rpm /opt/rpm4/bin/rpm /SUSE91/bin/rpm: ELF [..], dynamically linked (uses shared libs), stripped /bin/rpm: ELF [..], statically linked, stripped /opt/rpm4/bin/rpm: ELF [..], statically linked, not stripped SuSE hat rpm jedenfalls mal statisch gelinkt. /opt/rpm4 ist ein selbstgebackenes rpm4 das ich primaer dazu verwende rpm4 rpms auszupacken (mit rpm2cpio). -dnh -- Gib mal Patschehändchen und komm mit dem freundlichen Wokoonkel nach dag. Da brauchen wir noch Leute wie dich. [WoKo in dag°]

On Thu, 22 Dec 2005 19:01:16 +0100, Steffen Dettmer wrote:

Dynamisch gelinkter Installer ist schon bissel interessant.

Auf einem System, welches die glibc verwendet, *darf* rpm nicht statisch gelinkt werden, denn rpm benutzt Funktionen zur Namensauflösung, die seit Einführung des nsswitch *grundsätzlich* dynamisch geladen werden.

50% wissen vermutlich gar nicht mehr, was statisches Linken eigentlich ist.

Wie gesagt, dass ist mit der glibc auch nur noch bedingt möglich.

Ist halt der "Preis" für Mainstream und Massenware.

Statisches Linken macht doch heute nur noch bedingt Sinn. Philipp

Steffen Dettmer schrieb:

* Philipp Thomas wrote on Fri, Dec 23, 2005 at 00:58 +0100:

...

denn rpm benutzt Funktionen zur Namensauflösung, die seit Einführung des nsswitch *grundsätzlich* dynamisch geladen werden.

Hast Du da nähere Informationen dazu, einen Link oder so?

Nein, da habe ich derzeit nichts zur Hand.

Warum darf ich nicht statisch linken, wenn ich Namen auflösen möchte?

Naja, "darfst nicht" ist vieleicht zu stark ausgedrückt. Du darfst ja, wenn du dir der Einschränkungen bewusst bist. Um die Auflösung von Namen zur Laufzeit konfigurierbar zu machen, ersann Sun den nsswitch, der dann auch in der glibc implementiert wurde. Damit kannst du zur Laufzeit über /etc/nsswitch.conf bestimmen, welche Dienste zur Namensauflösung (wie z.B. mittels gethostbyname()) benutzt werden. Damit das funktioniert, sind die dienstspezifischen Zugriffsroutinen in einzelne dynamische Bibliotheken (libnss_*) gekapselt, die *grundsätzlich* dynamisch geladen werden, auch wenn die glibc statisch gelinkt wird. Somit bekommst du *nie* ein völlig statisch gelinktes Programm welches unabhängig von dynamischen Bibliotheken ist. Ausserdem ist dieses Programm nun abhängig von einer bestimmten Version der libnss_* Bibliotheken (diejenigen die zu der statisch gelinkten glibc gehören). Genau aus diesem Sachverhalt kannst du übrigens auf Solaris von vornherein kein Programm statisch linken, das diese Funktionen zur Namensauflösung verwendet. Wird nun die glibc durch eine neuere Version ersetzt, bei welcher die Schnittstelle zwischen libnss_* und der glibc nicht mehr kompatibel ist, hört das Programm auf zu funktionieren. Und genau das ist in der Vergangenheit schon mal passiert, weshalb dann bei Spezialisten, die unbedacht nur die glibc aktualisierten, Programme wie rpm sich mit segfault oder Ähnlichem verabschiedeten. Wenn also vollstatisch für solche Programme eh nicht möglich ist, sollte man sie gleich dynamisch linken, zumindest gegen die glibc.

Aber warum denn? Plattenplatz ist doch billig?

Ja, hauptsächlich der Plattenplatz. Aber dynamische Bibliotheken haben ja auf Vorteile bei der Belegung von Hauptspeicher. Philipp

* David Haller wrote on Sat, Dec 31, 2005 at 04:43 +0100:

Ich finde es jedenfalls nervig, dass dadurch durch die Hintertuer ein '-static' Binary doch nicht "static" ist... Die Einschraenkungen bei der Namensaufloesung dadurch, dass "nur" libnss_{foo,bar}.a gelinkt werden wuerde ich in Kauf nehmen (bzw. "compile-time-configurable" machen oder so).

libnss_{foo,bar}.a gibt es erst gar nicht, nur .so's und in libc_nonshared.a ist es auch nicht drin. Ja, Du brauchst tatsächlich ein funktionierenden dynaloader, um eine Textdatei wie /etc/hosts zu lesen.

Oder warum man nicht auf einen "Plugin"-Mechanismus zurueckgreift...

Ist libdl ja eigentlich. Je nach dem, wie gethostbyname und Freunde implementiert sind, kommt dann halt NULL zurück - fragt sich nur, ob die Applikationen (Yast, ...) damit umgehen können. Jedenfalls kann man Applikationen schreiben, die damit klarkommen, wir hatten mal sowas, so nach dem Motto "ist Spezial-so nicht da, probieren wird Standard-so, ist auch das nicht da, gibt's schöne Logeinträge etc. Das ist IMHO OK: Die fehlenden Funktionalität fehlt logischerweise, aber auch nicht mehr. Aber ich hab den ganzen Kram eh nicht verstanden (sprich: aus dem Bauch herraus finde ich es einfach falsch) - meiner Meinung nach sollte ein Entwickler entscheiden, ob seine Applikation dynamisch oder statisch gelinkt werden soll, und nicht eine libc_nonshared.a von libnss_*.so abhängen. Ich hab in einer Mail an Philipp schon gealbert, dass man jetzt noch ne Java JVM einbauen sollte, damit der custom-Resolver auch in Java geschrieben werden kann - weil z.B. mein HTTP/SOAP Application Server einen Namesdienst anwendet oder ein multithreaded CORBA Service oder so - beides hängt natürlich vorher vom Stage-1 resolving ab - man muss ja erstmal den Dienst selbst connecten (und natürlich über DNS Namen). Dann dauert eine Auflösung zwar schnell mal > 1000 ms, aber kann dafür viel bunter werden, z.B. mit X11 "Progress-Bar-GUI", wenn DISPLAY gesetzt ist... SCNR.

(da gibt's ja Beispiele, z.B. perl, xmms u.a., wo die plugins (dyn-libs) eben per dlopen geladen werden -- oder beisst sich dlopen generell mit statisch gelinkt?)...

Nein, es funktioniert ja. Ich hab mal ein Testprogramm gemacht, das gethostbyname aufruft und statisch gelinkt ist. Im strace sieht man, dass dann die .so geöffnet wird. Hab jetzt nicht getestet, was passiert, wenn das schiefgeht (also ob da dann einfach NULL zurückkommt, oder ob da vielleicht sogar jemand abort() aufruft oder SIGSEGV verursacht). Wie Du schon geschrieben hast: "durch die Hintertuer", man merkt es erst, wenn man ein Problem mit der libc hat /und/ zur Laufzeit ein gethostbyname oder so braucht. Vermutlich gibt's irgendeinen Grund dafür, google hat mir auf die Schnelle nix erzählt, jedenfalls gefällt es mir nicht, dass ich selbst bei der libc symbolprobleme jetzt erst zur Laufzeit merke und nicht mehr zur Compilezeit. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.

David Haller schrieb:

Programme mit '-Wl,-rpath,/usr/local/gcc/4.0.2/lib' zu kompilieren.

Pfui! Von rpath sollte man wenn möglich die Finger lassen, weil es mehr Probleme macht als löst. Philipp

David Haller schrieb:

-v bitte

Sollst du haben :)

Beachte: es geht um mehrere GCC-Versionen. Ich habe z.B. nen egcs-2.91.66 in /usr, nen pgcc-2.95.2+athlon-patch 2.95.3 in /usr/local (mit dem ich inzwischen grosse Teile des Systems, u.a. den Kernel kompiliert habe) sowie gcc-2.95.3,

Zumindest diese Gruppe ist bestenfalls Steinzeit. Lass mal einen von denen über die Testsuite eines 4'er gcc laufen und du wirst sehen, was ich meine.

gcc-3.3.5 und geplant nen gcc-4.0.x in /opt/gcc/$VERSION.

Erklaere mir bitte, was daran "pfui" ist. Fuer mich liest sich das wie eine im Binary-kodierte LD_LIBRARY_PATH (bzw. LD_RUN_PATH) Erweiterung.

rpath verdrahtet den Pfad zur Bibliothek hart im Programm. Damit sucht das Programm auch dann in dem Pfad, wenn die Bibliothek verschoben wurde. Für die Distribution werden deshalb auch die Vorkommen von -rpath eliminiert. Philipp

Am Mittwoch, 21. Dezember 2005 00:49 schrieb Philipp Thomas:

(...). BTW, die Bibliothek libgcc_s.so darf nur einmal im System vorhanden sein, wenn Exceptions in C++ vernünftig funktionieren sollen! (...).

Da hake ich mich mal ein, weil ich eben ein Problem mit den C++-Exceptions habe: Ich habe hier ein größeres C++-Softwareprojekt, was unter SL 7.x wunderbar läuft. Unter SL 8.1 mit dem gcc-2.95.3 auch noch. Aber unter SL 10.0 (mit dem gcc_old-2.95.3-92.i586.rpm von ftp.suse.com oder einem selbstkompilierten) schmeißen C++-Exception ein SIGABRT, sobald diese Exceptions in hinzugelinkten Komponenten geworfen werden. Für jede Hilfe diesbezüglich wäre ich extrem dankbar! Jan -- The worst form of inequality is to try and make unequal things equal.

Am Mittwoch, 21. Dezember 2005 09:29 schrieb Philipp Thomas:

On Wed, 21 Dec 2005 01:36:14 +0100, Jan Ritzerfeld wrote:

...

Aber unter SL 10.0 (mit dem gcc_old-2.95.3-92.i586.rpm von ftp.suse.com oder einem selbstkompilierten)

Sprich in beiden Fällen mit einem gcc 2.95.3?

Richtig. Unter SL 8.1 und 10.0 mit dem gcc 2.95.3, unter SL 7.x mit dem 2.95irgendwas (dem gcc von den CDs).

...

schmeißen C++-Exception ein SIGABRT, sobald diese Exceptions in hinzugelinkten Komponenten geworfen werden.

*Alle* beteiligten Komponenten inklusive der Bibliotheken (sofern es C++ Bibliotheken sind) *müssen* mit 2.95.3 kompiliert worden sein, da sich zwischen 2.95.3 und 4.0.2 mindestens zweimal das C++ ABI inkompatibel geändert hat.

Jau. Gibt lustige Fehler. Aber hauptsächlich beim kompilieren. Es werden in diesem Projekt alle Libraries selbst kompiliert und nur die aus dem Projekt benutzt, um eben unabhängig von dem eigentlichen System zu sein. Die libstdc++ wird auch aus dem entsprechenden gcc-Verzeichnis benutzt. Und der Witz ist ja, daß es unter SL 8.1 mit dem gcc 2.95.3 wunderbar funktioniert.

Wenn es das nicht ist, müsste ich mal versuchen, mich intern schlau zu machen.

Das wär klasse. Das was noch aus dem System benutzt wird ist die glibc, insbesondere /lib/ld-2.3.x.so. Und SL 8.1 und 10.0 basieren ja auf unterschiedlichen glibc-Versionen. Ein einfaches Beispielprogramm, bei dem das Problem auch auftritt, habe ich leider nicht hinbekommen. Das Problem tritt scheinbar nur dann auf, wenn man mehrere Objekt-Dateien mit selbstkompilierten Libraries zusammenlinkt. Letztlich verhält sich das Programm so, als hätte man eine Exception geworfen, die nicht gefangen wird bzw. werden kann, weil es kein passendes catch gibt. Aber es sind selbstdefinierte Exception-Objekte, die eigentlich alle mit catch(exception& e) gefangen werden müßten. TIA Jan -- You can't guard against the arbitrary.

Thomas Hertweck wrote:

Wieso? Er installiert ja nicht nach /usr/local/bin und /usr/local/lib, sondern nach /usr/local/gcc/bin und /usr/local/gcc/lib, es sollte somit zu keinen Kollissionen kommen.

Ja, das sollte funktionieren. Sorry, da habe ich in der Eile das /gcc übersehen. Philipp