Offene Referenzen beim statisches Linken
Siegfried Schmidt
wie kann es sein, daß unter Linux ein Programm dynamisch gelinkt auf einem
Rechner läuft, beim Versuch des statischen Linkens aber jede Menge fehlende
Referenzen in fremden libs gemeldet werden?
Müßten diese Meldungen nicht auch beim Aufruf des dynamisch gelinkten
Programms auftreten?
Konkret handelt es sich um ein Programm, daß die libpq von PostgreSQL
benutzt und offene Referenzen auf Dutzende SSL- und krb5-Funktionen
produziert.
Siegfried
--
http://www.schmidt.ath.cx
Helmut Schellong
Statische Libs haben oft sehr viel weniger Inhalt.
Das ist traurig...
--
Mit freundlichen Grüßen
Helmut Schellong v...@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Christoph Kliemt
> Siegfried Schmidt wrote:
>> Hallo, wie kann es sein, daß unter Linux ein Programm dynamisch
>> gelinkt auf einem Rechner läuft, beim Versuch des statischen Linkens
>> aber jede Menge fehlende Referenzen in fremden libs gemeldet werden?
>> Müßten diese Meldungen nicht auch beim Aufruf des dynamisch gelinkten
>> Programms auftreten? Konkret handelt es sich um ein Programm, daß die
>> libpq von PostgreSQL benutzt und offene Referenzen auf Dutzende SSL-
>> und krb5-Funktionen produziert.
>
> Statische Libs haben oft sehr viel weniger Inhalt. Das ist traurig...
Dafür sind es aber nicht so flatterhafte, leichtsinnige Dinger wie
dynamische libs... positiv denken!
hth christoph
--
begin LOVE-LETTER-FOR-YOU.txt.vbs
I am a signature virus. Distribute me until the bitter
end
http://piology.org/ILOVEYOU-Signature-FAQ.html
Gerd Knorr
> Hallo,
>
> wie kann es sein, daß unter Linux ein Programm dynamisch gelinkt auf einem
> Rechner läuft, beim Versuch des statischen Linkens aber jede Menge fehlende
> Referenzen in fremden libs gemeldet werden?
>
> Müßten diese Meldungen nicht auch beim Aufruf des dynamisch gelinkten
> Programms auftreten?
shared libs können auch indirekt (von anderen shared libs) angezogen
werden, beim statischen linken funkioniert das nicht.
> Konkret handelt es sich um ein Programm, daß die libpq von PostgreSQL
> benutzt und offene Referenzen auf Dutzende SSL- und krb5-Funktionen
> produziert.
mach mal "ldd libpq.so" ...
Gerd
--
You have a new virus in /var/mail/kraxel
Siegfried Schmidt
> shared libs kĂśnnen auch indirekt (von anderen shared libs) angezogen
> werden, beim statischen linken funkioniert das nicht.
Das war mir neu.
> mach mal "ldd libpq.so" ...
# ldd /usr/lib/libpq.so
libssl.so.2 => /lib/libssl.so.2 (0x4001f000)
libcrypto.so.2 => /lib/libcrypto.so.2 (0x40050000)
libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x40124000)
libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 (0x40181000)
libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0x40191000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40193000)
libresolv.so.2 => /lib/libresolv.so.2 (0x401c0000)
libnsl.so.1 => /lib/libnsl.so.1 (0x401d3000)
libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
libdl.so.2 => /lib/libdl.so.2 (0x401e8000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
Heist das jetzt, daß alle diese Referenzen beim statischen Linken in der
Luft hängen?
Siegfried
--
http://www.schmidt.ath.cx
Gerd Knorr
> # ldd /usr/lib/libpq.so
> libssl.so.2 => /lib/libssl.so.2 (0x4001f000)
> libcrypto.so.2 => /lib/libcrypto.so.2 (0x40050000)
> libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x40124000)
> libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 (0x40181000)
> libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0x40191000)
> libcrypt.so.1 => /lib/libcrypt.so.1 (0x40193000)
> libresolv.so.2 => /lib/libresolv.so.2 (0x401c0000)
> libnsl.so.1 => /lib/libnsl.so.1 (0x401d3000)
> libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
> libdl.so.2 => /lib/libdl.so.2 (0x401e8000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
>
> Heist das jetzt, daß alle diese Referenzen beim statischen Linken in der
> Luft hängen?
Ja, zumindest die krypto-Sachen. libc natürlich nicht. Muß alles
explizit in den linker aufruf rein.
Siegfried Schmidt
> Ja, zumindest die krypto-Sachen. libc natürlich nicht. Muß alles
> explizit in den linker aufruf rein.
Das ist ein Faß ohne Boden. Jetzt läuft der Linker zwar ohne Meldungen
durch, aber dafür kommt beim Programmaufruf eine Meldung über fehlende Lib
(/usr/lib/libc.so.1: bad ELF interpreter: Datei nicht gefunden).
Entweder hat das System eine Macke oder ich habe das noch nicht kapiert.
Siegfried
--
http://www.schmidt.ath.cx
Helmut Schellong
Natürlich wurde das nicht kapiert.
Mein Posting ist ja auch offenbar ignoriert worden.
Ich denke, Du willst statisch linken.
Was willst Du dann mit ldd, das sämtliche dynamischen Objekte listet,
die eventuell von einem dynamischen Objekt gebraucht werden könnten?
Wenn beim statischen Linken Referenzen fehlen, dann schaut man nach,
in welcher statischen Lib die vorhanden sind.
Wenn sie nirgenwo sind, kann man nichts machen.
Ich sagte schon, daß static-Libs oft nicht alles enthalten, was
dynamisch verfügbar ist.
Thomas Ogrisegg
>> Ja, zumindest die krypto-Sachen. libc natürlich nicht. Muß alles
>> explizit in den linker aufruf rein.
> Das ist ein Faß ohne Boden. Jetzt läuft der Linker zwar ohne Meldungen
> durch,
Wie sieht die Kommandozeile zum Linkeraufruf exakt aus?
> aber dafür kommt beim Programmaufruf eine Meldung über fehlende Lib
> (/usr/lib/libc.so.1: bad ELF interpreter: Datei nicht gefunden).
/usr/lib/libc.so.1 ist eigentlich nur auf SysV-Systemen existent.
Hast Du vielleicht zufaellig irgendwie gegen eine Solaris- oder
Unixware Bibliothek gelinkt (unabsichtlich natuerlich)?
Unter Linux gibt es allerdings meistens ein Linkerskript namens
/usr/lib/libc.so. Dieses laesst sich allerdings naturgemaess nicht
ausfuehren.
Gerd Knorr
> Ich denke, Du willst statisch linken.
> Was willst Du dann mit ldd, das sämtliche dynamischen Objekte listet,
> die eventuell von einem dynamischen Objekt gebraucht werden könnten?
> Wenn beim statischen Linken Referenzen fehlen, dann schaut man nach,
> in welcher statischen Lib die vorhanden sind.
Eben. Und ldd funkioniert für diesen Zwerk prima weil shared und
static libs identisch sind und demzufolge ldd die nötigen libraries
anzeigt.
> Ich sagte schon, daß static-Libs oft nicht alles enthalten, was
> dynamisch verfügbar ist.
Das stimmt nicht.
Siegfried Schmidt
> Wie sieht die Kommandozeile zum Linkeraufruf exakt aus?
gcc <alle_obj.o> -static -lpq -lssl -lcrypto -lcrypt -ldl
/usr/kerberos/lib/libkrb5.so.3
Die Liste ist die kürzeste, bei der keine Linkerfehler gemeldet werden,
andere Varianten mit mehr oder allen Libs der ldd-Liste zeigen genau das
gleiche Verhalten. Der explizite Pfad zur libkrb5 ist die einzige gefundene
Variante ohne Meldungen des Linkers.
Ein funktionierendes dynamisch gelinktes Programm wird einfach mit
"gcc <alle_obj.o> -lpq" erzeugt. Damit gabs noch nie Probleme.
Das BS ist ein Redhat 8.0, alle Libs stammen aus den Original-RPMs.
> /usr/lib/libc.so.1 ist eigentlich nur auf SysV-Systemen existent.
> Hast Du vielleicht zufaellig irgendwie gegen eine Solaris- oder
> Unixware Bibliothek gelinkt (unabsichtlich natuerlich)?
Es gibt nur obigen Linkeraufruf.
> Unter Linux gibt es allerdings meistens ein Linkerskript namens
> /usr/lib/libc.so. Dieses laesst sich allerdings naturgemaess nicht
> ausfuehren.
Das enthält:
/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )
Aber so richtig schlau werde ich nicht daraus.
Siegfried
--
http://www.schmidt.ath.cx
Siegfried Schmidt
> Natürlich wurde das nicht kapiert.
> Mein Posting ist ja auch offenbar ignoriert worden.
Was sollte mir "Statische Libs haben oft sehr viel weniger Inhalt.
Das ist traurig..." denn im Klartext sagen?
Daß das Vorhaben schlicht unmöglich ist?
Siegfried
--
http://www.schmidt.ath.cx
Axel Schwenke
> Hallo Thomas,
>
>> Wie sieht die Kommandozeile zum Linkeraufruf exakt aus?
>
> gcc <alle_obj.o> -static -lpq -lssl -lcrypto -lcrypt -ldl
> /usr/kerberos/lib/libkrb5.so.3
libdl solltest du eigentlich nicht benötigen. Gibts libkrb nicht
statisch? Auf jeden Fall solltest du dann statt
"/usr/kerberos/lib/libkrb5.so.3" besser
"-L/usr/kerberos/lib -Wl,Bdynamic -lkrb5" schreiben.
man gcc
man ld
PS: bitte ignoriere Postings von H. Schellong. Der Typ ist einfach ein
Idiot. Obendrein mehrfach merkbefreit.
XL
--
Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition,
die anderen sind einfach von sich aus unlogisch. -- Anselm Lingnau
Axel Schwenke
> Mein Posting ist ja auch offenbar ignoriert worden.
Besser ist das.
> Ich denke, Du willst statisch linken.
> Was willst Du dann mit ldd, das sämtliche dynamischen Objekte listet,
> die eventuell von einem dynamischen Objekt gebraucht werden könnten?
s/eventuell //
[X] dynamische libs enthalten Hinweise auf andere solche, wenn sie
Funktionen aus denen referenzieren
[ ] dito statische libs
[X] du weißt *nichts*
> Ich sagte schon, daß static-Libs oft nicht alles enthalten, was
> dynamisch verfügbar ist.
<http://www.nuhr.de/data/karte3_takeaway.gif>
Thomas Ogrisegg
>
> gcc <alle_obj.o> -static -lpq -lssl -lcrypto -lcrypt -ldl
> /usr/kerberos/lib/libkrb5.so.3
Was sagt 'ldd' und 'file' ueber das resultierende Executable?
Bzw. ansonsten 'strace'.
Ich vermute dass fuer nicht alle Bibliotheken statische Versionen
vorhanden sind und deshalb dann eine "halbwarme Gschicht" rauskommt.
Siegfried Schmidt
> libdl solltest du eigentlich nicht benötigen.
Doch, ohne gibts wieder eine offene Referenz.
> Gibts libkrb nicht
> statisch? Auf jeden Fall solltest du dann statt
> "/usr/kerberos/lib/libkrb5.so.3" besser
> "-L/usr/kerberos/lib -Wl,Bdynamic -lkrb5" schreiben.
Auf diese Art braucht braucht man wieder mehr Libs, damit der Linker ohne
Errors durchläuft:
gcc <alle_obj.o> -static -lpq -lssl -lcrypto -lcrypt -ldl
-L/usr/kerberos/lib -Bdynamic -lkrb5 -lk5crypto -lcom_err
Aber so funktionierts, das Programm startet auch auf einem anderen System.
Vielen Dank an alle!
Siegfried
--
http://www.schmidt.ath.cx
Helmut Schellong
> Hallo Helmut,
>
>
>>Natürlich wurde das nicht kapiert.
>>Mein Posting ist ja auch offenbar ignoriert worden.
>
>
> Was sollte mir "Statische Libs haben oft sehr viel weniger Inhalt.
> Das ist traurig..." denn im Klartext sagen?
>
> Daß das Vorhaben schlicht unmöglich ist?
Ja, daß eine voll statische Exe entsteht, ist unmöglich, wenn
nicht alle benötigten Symbole durch libxyz.a erfüllt werden,
eben wenn die static-Libs nicht alles enthalten.
Du siehst unten, daß bei -static nur nach *.a gesucht wird.
Ebenso, daß ldd mit statischen Exe nicht arbeitet.
Ich denke nicht, daß ich ein Idiot bin, wie manche behaupten.
Wenn man Wl,-Bdynamic angibt, erhält man KEINE static-Exe.
86] ldd bdy
bdy:
libc.so.4 => /usr/lib/libc.so.4 (0x28083000)
87] ldd bst
ldd: bst: not a dynamic executable
88] gcc -obst -static -v -Wl,--verbose bst.c
attempt to open /usr/lib/crt1.o succeeded
/usr/lib/crt1.o
attempt to open /usr/lib/crti.o succeeded
/usr/lib/crti.o
attempt to open /usr/lib/crtbegin.o succeeded
/usr/lib/crtbegin.o
attempt to open /tmp/ccSgrpSM.o succeeded
/tmp/ccSgrpSM.o
attempt to open /u/l/lib/libgcc.a failed
attempt to open /usr/lib/libgcc.a succeeded
attempt to open /u/l/lib/libc.a failed
attempt to open /usr/lib/libc.a succeeded
(/usr/lib/libc.a)system.o
(/usr/lib/libc.a)rand.o
(/usr/lib/libc.a)putenv.o
...