Discussion :

[Christophe]

Bonsoir,

Je n'arrive pas à créer et utiliser une bibliothèque sous Linux. Voici mon code :
test.c :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
#include "my_lib/testlib.h"
 
int main(void)
{
    affichage("Hello World");
    return 0;
}

mylib/testlib.h :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
#define _GNU_SOURCE
#include <stdio.h>
#include <dlfcn.h> 
 
extern int affichage(const char *message);

mylib/testlic.c :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
#include "stdio.h"
 
int affichage(const char *message)
{
	int result=puts("Hello World\n");
	return result;
}

Je compile la bibliothèque comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
cd mylib
gcc -c -fPIC testlib.c 
gcc -shared -Wl,-soname,mylib.so.1 testlib.o -o mylib.so.1

et pour le fichier test :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
gcc -c test.c -l<chemin de ma bibliothèque> -o test

La biliothèque semble ok (si j'utiloise objdump, je vois bien ma fonction affichage)

Par contre le fichier test compilé est un fichier ELF (file test retourne binen un format ELF), mais il est invalide.
ldd test me répond "n'est pas un executable dynamique".

Merci pour votre aide.

[Obsidian]

Bonjour,

Il faut retirer l'option « -c » quand tu compiles test.c

[Christophe]

Merci pour ton retour Obsidian, mais si je ne mets pas -c, j'ai l'erreur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

collect2: error: ld returned 1 exit status

J'ai essayé du coup en faisant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
gcc test.c
gcc test.o -l/<bibliothèque> -o test

[ternel]

pour gcc, l'option -c signifie "s'arreter avant l'édition des liens".
donc, c'est soit:

gcc -c test.c
gcc test.o -lmylib -o test

soit:

gcc test.c -lmylib -o test

-lmylib indique à gcc qu'il doit trouver une bibliothèque mylib (libmylib.so dans ton cas) lors de l'édition des liens.

a priori, tu dois penser à créer (dans le même dossier que ton exécutable) un lien nommé libmylib.so vers libmylib.so.1

[Christophe]

Merci pour vos retours
Je viens de m'en sortir comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
cd mylib
gcc -fPIC -c mylib.c
gcc -shared -o libmylib.so mylib.o
cd ..
gcc -o test test.c -lmylib -L/<chemin>
LD_LIBRARY_PATH=$PWD/mylib
export LD_LIBRARY_PATH

Je pense que je vais cafouiller encore un peu notamment avec l'option -lmylib. Je ne vois pas comment se fait le rapport entre mylib et libmylib et du coup, comment ça fonctionne si j'ai un second fichier .c venant dans la bibliothèque, mais ce sera une autre étape.

L'utilisation de LD_LIBRARY_PATH est pour éviter de copier la bibliothèque dans /lib. L'idéal serait l'utilisation d'un chemin relatif mais j'ai pas l'impression que c'est possible.

[ternel]

-lbidule cherche libbidule.so ou libbidule.a dans le LD_LIBRARY_PATH et quelques dossiers systèmes (dont /usr/lib)
le nom bidule est ici totalement indépendant des noms des .c / .o.

Par ailleurs, tu n'est pas obligé d'exporter la variable shell, cela éviterai de polluer certains scripts.

[sambia39]

Bonjour
Effectivement "-c" permet de faire appel au pré-processeur qui par la suite doit effectuer la compilation et l'assemblage sans faire l'édition de liens et donc seuls les fichiers objets ".o" vont être générés.
Cependant vous avez la possibilité de faire tout simplement :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
gcc -Wall -Werror -c -fPIC source_lib.c -o source_lib.o
gcc -o libMylib.so -shared -Wl source_lib.o
gcc *.c -Wall -Werror -g -D_GNU_SOURCE -lMylib -L. -o Deb
./Deb

.....
Je pense que je vais cafouiller encore un peu notamment avec l'option -lmylib. Je ne vois pas comment se fait le rapport entre mylib et libmylib et du coup, comment ça fonctionne si j'ai un second fichier .c venant dans la bibliothèque, mais ce sera une autre étape.

L'utilisation de LD_LIBRARY_PATH est pour éviter de copier la bibliothèque dans /lib. L'idéal serait l'utilisation d'un chemin relatif mais j'ai pas l'impression que c'est possible.

Le nom d’une bibliothèque n’est pas seulement le nom du fichier, mais plutôt le nom propre de la bibliothèque et il est contenu dans le fichier en question c’est également grâce à ce nom que le chargeur des bibliothèques dynamiques se réfère et non au nom de fichier. Par convention sur des systèmes UNIX ou GNU/Linux les bibliothèques statique ou dynamique commencent tous avec les trois lettres "lib" (sans trop allée dans les détail faite un tour dans ls /opt/local/lib pour constater).
Ceci dis, vous n’avez pas besoin d’exporter la variable d’environnement dès lors ou la bibliothèque partagée se trouve dans le même répertoire que les sources un

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

gcc *.c -Wall -Werror -g -D_GNU_SOURCE -lMylib -L. -o Deb

suffit largement car la "libMylib.so" est dans le répertoire courant avec les fichiers de compilation. Vous allez utiliser les variables d’environnement uniquement lorsque vous devez ajouter des répertoires pertinents au chemin de recherche de votre bibliothèque ou autres.

Vous avez également la possibilité de concevoir votre bibliothèque dynamique en utilisant les outils GNU "libtool" qui vous simplifie le processus de création de vos bibliothèques partagées, en particulier celles destinées à être utilisées sur plusieurs plates-formes.

à bientôt

[Christophe]

Vous avez également la possibilité de concevoir votre bibliothèque dynamique en utilisant les outils GNU "libtool" qui vous simplifie le processus de création de vos bibliothèques partagées, en particulier celles destinées à être utilisées sur plusieurs plates-formes.

En faisant des recherches j'étais tombé dessus. Je me le gardais comme plan B.

Le nom d’une bibliothèque n’est pas seulement le nom du fichier, mais plutôt le nom propre de la bibliothèque et il est contenu dans le fichier en question

Je pense qu'il s'agit du soname.

Le -L. ça m’intéresse, je vais regarder si ça fonctionne.

[Christophe]

Voici la solution permettant l'utilisation d'une bibliothèque dans le même dossier que l'exe et sans utilisation de LD_LIBRARY_PATH. J'ai testé sur une autre machine, ça fonctionne.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
#!/bin/bash
cd mylib
gcc -fPIC -c mylib.c
gcc -o libmylib.so -shared mylib.o
mv libmylib.so ../
cd ..
gcc test.c -lmylib -L. -Wl,-R. -o test

[LittleWhite]

C'est quoi ce -R ?
J'aurais pensé à l'option -rpath.

[picodev]

C'est la même chose (mais en ancien dialecte ) :

-R filename
--just-symbols=filename
Read symbol names and their addresses from filename, but do not relocate it or include it in the output.
This allows your output file to refer symbolically to absolute locations of memory defined in other
programs. You may use this option more than once.

For compatibility with other ELF linkers, if the -R option is followed by a directory name, rather than a
file name, it is treated as the -rpath option.

Tiré de la man page de ld.

[LittleWhite]

Je m'en doutais mais pas fainéantise me suis arrêté à la manpage de GCC

[picodev]

En même temps, le rpath (sauf en mode développement) ça ne sert à rien. À quoi bon mettre en dur un chemin sur une bibliothèque partagée ? autant en faire une bibliothèque statique ; c'est un peu contre nature ce rpath (sauf cas assez particuliers).

[Christophe]

En même temps, le rpath (sauf en mode développement) ça ne sert à rien. À quoi bon mettre en dur un chemin sur une bibliothèque partagée ? autant en faire une bibliothèque statique ; c'est un peu contre nature ce rpath (sauf cas assez particuliers).

ben c'est un peu mon cas, le but étant de ne pas mettre la bibliothèque dans /lib le temps du développement. On a 2 solutions.

En tout cas on ne pourra pas dire que ça manque de souplesse.