Unix - AIX - libc.a Verwirrung

codefrag

Hallo Kollegen,
vielleicht könnt ihr mir folgendes Problem erklären. Bisher dachte ich das die libc library als static und shared ausgeliefert wird.

Nun ist mir aufgefallen das unter AIX 5L nur die libc.a Library existiert.

Folgenden Output ergibt ein "file":

/usr/lib > file /usr/lib/libc.a
/usr/lib/libc.a: archive (big format)

Bei einem dump -a sehe ich die ganze object files die in die library gepackt wurden. Als Beispiel ein kleiner Auszug hiervon:

/usr/lib > dump -a /usr/lib/libc.a | more
***Archive Header***
Member Name Date Uid Gid Mode Size
frexp.o Jul 12 17:09:00 2004 300 300 000640 0x00000650
itrunc.o Jul 12 17:09:01 2004 300 300 000640 0x000002ee
ldexp.o Jul 12 17:09:01 2004 300 300 000640 0x000007a6
......

Also nach meinen Verständis müsste jedes Binary das die libc Funktionen verwendet statisch auf die Library libc.a gelinked sein - so das die Binaries die Funktionen im Bauch haben - richtig?

Nun schaut euch aber mal den ldd Output vom Binary "ls" an:

/usr/lib > ldd /usr/bin/ls
/usr/bin/ls needs:
/usr/lib/libc.a(shr.o)
/unix
/usr/lib/libcrypt.a(shr.o)

hmmm und jetzt verwirrt es mich.. Wieso benötigt das Binary "ls" die Library libc.a (welche ja laut file eine statische ist)?
Wie kann das funktionieren?

Ich habe testweise auch einmal die libc.a in einen anderen Ordner verschoben - danach ging gar nichts mehr da ständig Loaderfehler bei allen Binaries kamen -> siehe hier:

Could not load program telnetd:
Dependent module libc.a(shr.o) could not be loaded.
Could not load module libc.a(shr.o).
System error: No such file or directory

Nachdem ich den LIBPATH dann wieder auf den Pfad in den ich die libc.a verschoben hatte erweitert habe, hat es wieder funktioniert.

Kann mir das mal jemand erklären wie eine statische Library zu einer dynmaische "umfunktioniert" wird?

Der file Output bei Shared Libraries (.so Dateien) sieht dann folgendermaßen richtig aus:

/usr/lib > file libtcl8.3.so
libtcl8.3.so: executable (RISC System/6000) or object module not stripped

Wäre super wenn mir das jemand plausibel erklären könnte.

rüdiger

Ich habe keine Erfahrung mit AIX, daher kann ich nur raten:

Lass dir vielleicht mal die Symbole in einem Programm anzeigen und überprüfe ob diese definiert sind (Text-Section). Zur Anzeige der Symbole kannst du man: nm(1) verwenden (aus den GNU/binutils, die sollte es auch für AIX geben). Das shr.o aus libc.a(shr.o) klingt für mich sehr stark nach 'shared'

Kann vielleicht auch traditionell bedingt sein, dass die libc eine .a-Datei ist und der Code Code aus shr.o nachgeladen wird.

(Du könntest auch libc.a mal entpacken und schauen welche Symbole zB in shr.o stecken und welche nicht und dann ein Testprogramm schreiben, das einmal Symbole verwendet die in shr.o vorkommen und einmal Symbole die in shr.o nicht vorkommen aber in einem anderen Teil der libc. Dann schau danach noch einmal, welche symbole statisch gelinkt sind und welche nicht).

codefrag

rüdiger schrieb:

Kann vielleicht auch traditionell bedingt sein, dass die libc eine .a-Datei ist und der Code Code aus shr.o nachgeladen wird.

Geht sowas überhaupt?
Ich dachte bisher immer das eine Library entweder shared oder static ist und nicht irgendwelche Teile daraus static bzw. shared sein können.

rüdiger

wenn man will wird es gehen. Du musst den Code vermutlich nur an eine fixe Stelle im Speicher laden (geht prima mittels man: mmap(2)).

codefrag

rüdiger schrieb:

wenn man will wird es gehen. Du musst den Code vermutlich nur an eine fixe Stelle im Speicher laden (geht prima mittels man: mmap(2)).

Muss dies dann das jeweilige Programm machen oder macht das der Kernel?
Denn ich kann mir nicht vorstellen das jede Anwendung, die die libc Funktionen benutzt das so macht.

Denn wenn man die libc.a verschiebt, dann geht kein einziger Befehl mehr (z.b. ls oder mv).

hmm alles etwas sehr suspekt

rüdiger

Das wird vermutlich der Programm-Loader machen, also der Teil der dann deine main-Funktion aufruft. (und auch normalerweise die dynamischen Libraries lädt)

codefrag

rüdiger schrieb:

Das wird vermutlich der Programm-Loader machen, also der Teil der dann deine main-Funktion aufruft. (und auch normalerweise die dynamischen Libraries lädt)

hmm ok ... ich habe jetzt mal eine Software genommen die nicht im "Standard"-AIX enthalten ist..

Hier wieder der ldd Aufruf:

> ldd nmon_aix53
nmon_aix53 needs:
/usr/lib/libc.a(shr.o)
/usr/lib/libperfstat.a(shr.o)
/usr/lib/libcurses.a(shr42.o)
/usr/lib/libwlm.a(shr.o)
/unix
/usr/lib/libcrypt.a(shr.o)
/usr/lib/libpthreads.a(shr_xpg5.o)
/usr/lib/libcfg.a(shr.o)
/usr/lib/libodm.a(shr.o)
/usr/lib/liblvm.a(shr.o)
/usr/lib/libpthreads.a(shr_comm.o)

Dann habe ich jetzt folgende IBM Doku gefunden:
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.vacpp7a.doc/proguide/ref/compile_library.htm

Dort werden auch Shared Libraries als *.a Dateien erzeugt. Das verwirrt einen natürlich wenn man das Konzept von Linux mit *.a und *.so kennt.

Wichtig sind daher auch noch folgende 2 Auszüge:

(The default name of the shared object is shr.o, unless you use the -o option to specify another name.)

Optionally, use the AIX ar command to produce an archive library file from multiple shared or static objects

Also sind alle Binaries nicht statisch sondern dynamisch gegen die libc.a gelinked - die archive library beinhaltet somit shared und static objects und kann diese auch verwenden.

Worin der Unterschied zwischen den beiden Arten in der Doku besteht - verstehe ich trotzdem nicht -> siehe folgende Punkte:

Compiling a shared library
To create a shared library that uses static linking:
.....
.....

To create a shared library that uses run-time linking:

Was meint IBM mit "Use the -G option to create a shared library from the generated object files, to be linked at load-time" - ich dachte shared libraries werden immer zur Laufzeit dynamisch geladen.

Oder meint IBM mit "that uses static linking", das die shared library beim Starten des Programms geladen wird und bei "run-time linking" muß das Laden explizit mit dlopen() passieren?

Danke