libiconv : librairie statique ou partagée ?

Bonjour,

Dans mon programme j'utilise la fonction iconv() definie dans <iconv.h> .

Aucun problème quand je compile sous linux, mais quand je compile sous AIX, HPUX, ou MACOSX alors il est nécessaire d'inclure '-liconv' dans la commande de compilation. Avec ces 3 OSs la librairie n'est pas incluse dans l'exécutable, l'exécutable en est dépendant (shared library). Pourquoi est-ce que selon le système la librairie est liée ou incluse ? Y a t-il moyen de forcer la librairie à être "copiée" dans l'exécutable ?

Par ailleurs, si l'exécute la commande ldd sur mon exécutable (par exemple sous HPUX), j'obtiens la dépendance suivante:

/usr/local/lib/hpux32/libiconv.a (libiconv.so.2)

Là encore, les choses ne sont pas plus claires:

- d'après ce que je comprends, libiconv.so.2 est un symlink vers libiconv.a, mais où se trouve physiquement libiconv.so.2 ? J'ai cherché avec la commande 'find', mais je n'ai rien trouvé...

- en fin de compte mon programme dépend de libiconv.a, mais je croyais que les librairies portant l'extension '.a' étaient des librairies statiques. Pourquoi est-ce que j'ai ici un librairie partagée qui porte l'extension '.a'?

Merci d'avance pour tout éclaircissements.

Bonjour,

En effet, les fichiers *.a correspondent la plupart du temps aux bibliothèques statiques mais en réalité, c'est surtout l'extension de l'archiveur UNIX historique « ar » (apparu avant le « tape archiver » tar). Il s'agit donc d'un fichier archive basique contenant en fait des fichiers *.o, qui sont ni plus ni moins que les fichiers objets produits par le compilateur et qui peuvent être repris tels quels pour finaliser la compilation de l'application finale.

Il se peut donc que ce fichier contienne à la place une vraie bibliothèque partagée, ou que le système soit capable de la simuler à la volée. Que donne la commande suivante ?

Code:

---

$ ar t /usr/local/lib/hpux32/libiconv.a

---

Merci pour ta réponse.

La commande donne ceci:

Code:

---

1 2 3 4

# ar t /usr/local/lib/hpux32/libiconv.a iconv.o localcharset.o relocatable.o

---

Que peut-on en déduire?

Citation:

---

Envoyé par maa

Bonjour,

Dans mon programme j'utilise la fonction iconv() definie dans <iconv.h> .

Aucun problème quand je compile sous linux, mais quand je compile sous AIX, HPUX, ou MACOSX alors il est nécessaire d'inclure '-liconv' dans la commande de compilation. Avec ces 3 OSs la librairie n'est pas incluse dans l'exécutable, l'exécutable en est dépendant (shared library). Pourquoi est-ce que selon le système la librairie est liée ou incluse ? Y a t-il moyen de forcer la librairie à être "copiée" dans l'exécutable ?

---

Bonjour.
L'API iconv fait partie de la norme POSIX. Sous linux, cette API est directement incluse dans la glibc (c'est un choix des dèv). Comme tu limkes toujours avec la libc tu n'auras, sous linux, pas besoin d'autres options sur la ligne de commande du linker.
Apparemment les dèv sous AIX, HPUX et OSX n'ont pas fait le même choix et on décidé de placer les fonctions de la famille iconv dans une bibliothèque séparée.
On observe la même chose avec la libm qui selon les plateformes est ou non incluse dans la libc …

Citation:

---

Envoyé par maa

Par ailleurs, si l'exécute la commande ldd sur mon exécutable (par exemple sous HPUX), j'obtiens la dépendance suivante:

/usr/local/lib/hpux32/libiconv.a (libiconv.so.2)

Là encore, les choses ne sont pas plus claires:

- d'après ce que je comprends, libiconv.so.2 est un symlink vers libiconv.a, mais où se trouve physiquement libiconv.so.2 ? J'ai cherché avec la commande 'find', mais je n'ai rien trouvé...

- en fin de compte mon programme dépend de libiconv.a, mais je croyais que les librairies portant l'extension '.a' étaient des librairies statiques. Pourquoi est-ce que j'ai ici un librairie partagée qui porte l'extension '.a'?

Merci d'avance pour tout éclaircissements.

---

Peux-tu donner la sortie complète de ton ldd ?

Merci, ca s'eclaircit un peu. :)

voci la sortie complète du ldd sous HP-UX:

Code:

---

1 2 3 4 5 6

libiconv.so.7 => /usr/local/lib/gcc/ia64-hp-hpux11.23/4.2.3/../../../hpux64/libiconv.so.7 libm.so.1 => /lib/hpux64/libm.so.1 libpthread.so.1 => /lib/hpux64/libpthread.so.1 libc.so.1 => /lib/hpux64/libc.so.1 libc.so.1 => /usr/lib/hpux64/libc.so.1 libdl.so.1 => /usr/lib/hpux64/libdl.so.1

---

et voici ce que donne ldd sur AIX:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

/usr/lib/libc.a(shr_64.o) /usr/lib/libpthread.a(shr_xpg5_64.o) /usr/lib/libnsl.a(shr_64.o) /opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.8.2/../../../libiconv.a(libiconv.so.2) /unix /usr/lib/libcrypt.a(shr_64.o) /usr/lib/libpthreads.a(shr_xpg5_64.o) /usr/lib/libtli.a(shr_64.o) /usr/lib/libC.a(shr2_64.o) /usr/lib/libC.a(shr3_64.o) /usr/lib/libc.a(shr.o) /usr/lib/libc.a(pse_64.o) /usr/lib/libC.a(shrcore_64.o) /usr/lib/libC.a(ansicore_64.o) /usr/lib/libcrypt.a(shr.o) /usr/lib/libc_r.a(shr_64.o)

---

En fait je me rends compte que j'ai confondu HP-UX et AIX dans mon précédent post. Et je me rappelle que AIX autorise les librairies partagées à porter l'extension '.a'. C'est donc un peu moins bizarre que ce que je pensais au début.

Par contre je ne comprends toujours pas où se trouve physiquement libiconv.so.2 ou libiconv.so.7, ni comment le programme sait si il est dépendant de ".so.2" et ".so.7" ou ".so.714"... :roll:


PS: pour répondre à Obsidian, sur HPUX j'obtenais:

Code:

---

1 2 3 4 5

# ar t /usr/local/lib/hpux32/libiconv.a iconv.o localcharset.o relocatable.o

---

(car j'aussi un '.a' sur HP-UX mais peut-etre n'est-il pas utilisé par mon programme..)

et sur AIX:

Code:

---

1 2 3 4 5

# ar t libiconv.a libiconv.so.2 shr4.o shr.o

---