Discussion :

[Nico_stras]

Bonjour,
Ayant besoin de parser du XML dans une application embarquée, j'ai téléchargé les sources de expat.

De façon bête et méchante, je lance le script de config, puis un make.

De là, 2 répertoires sont créés :

/.libs
- libexpat.a
- libexpat.so
/lib/.libs
- xmlparse.o
- xmlrole.o
- xmltok.o

Quelles sont les utilisations possibles ?
Les fichiers *.o sont les fichiers temporaires ou ils peuvent être intégrés dans une application ?

Y-a-t-il un fichier .h à intégrer à mon application ?

Si je ne me trompe pas, *.a est une librairie statique (intégrée dans l'application), et *.so est une librairie partagée (chargé lors de l'utilisation)

Merci pour vos remarques.

Nicolas
Strasbourg

[Pouic]

Les fichiers *.o sont les fichiers temporaires ou ils peuvent être intégrés dans une application ?

Non, on s'en fout.

Y-a-t-il un fichier .h à intégrer à mon application ?

Oui, expat.h. Il y des exemples dans le tarball que tu récupères...

Si je ne me trompe pas, *.a est une librairie statique (intégrée dans l'application), et *.so est une librairie partagée (chargé lors de l'utilisation)

Oui.

[Nico_stras]

Si je ne me trompe pas, *.a est une librairie statique (intégrée dans l'application), et *.so est une librairie partagée (chargé lors de l'utilisation

Quelle est la meilleure solution ?
Y-a-t-il des différences en terme de performances ?

On trouve souvent des librairies en .so ; .so.a ; .so.2 ; ...
par exemple, fourni avec mon OS :
libexpat.so
libexpat.so.1
libexpat.so.2

De plus, libexpat.so = libexpat.so.2

Comment l'OS sait quelle version utiliser ?
Ce nom est-il dépendant de la version "expat-2.0.1"

[Gruik]

Quelle est la meilleure solution ?
Y-a-t-il des différences en terme de performances ?

Je crois que les bibliothèques partagées sont plus intéressantes en terme de perfs car elles sont chargées une seule fois par le système (c'est le cas de la bibliothèque standard du C) ; voir la commande "ldd" pour connaitre la liste des bibliothèques partagées utilisées par un programme.
Il y a une baisse de perf par contre si on utilise la bibliothèque comme un plugin en la chargeant manuellement à l'exécution (avec dl()) .

Utiliser une bibliothèque statique est parfois pratique si on veut lier une version très particulière dans un programme et être sur qu'il n'y aura pas d'effet de bord si on met à jour la bibliothèque partagée ; ceci a l'inconvénient de créer des binaires plus gros et donc plus lourd à charger par le système.

Pour les so.1, so.2.1.1, etc, ce sont différentes versions de la bibliothèque partagée, en général le .so est un lien symbolique sur une version spécifique

[souviron34]

De plus, libexpat.so = libexpat.so.2

Comment l'OS sait quelle version utiliser ?

En général le linker (ou loader pour les .so) cherche simplement les extensions "défaut" (.so, .a).

A l'installation de ton package (make install par exemple), on va créer donc ce nom par défaut, mais on le pointe symboliquement sur la bonne version... Comme ça, si tu updates ta bibliothèque, on n'a qu'à re-créer le lien symbolique... et tu as toujours tes 2 versions de biblothèques (et donc tu peux faire des comparaisons)