Version imprimable
Bonjour,
Je suis en train de travailler avec une API qu'un client m'a livré.
J'ai donc un fichier ex.so qui se trouve dans /rep/ .
Je compile en utilisant la commande :
gcc main.c -o main.exe -L /rep/ -l ex.so
et le ld me renvoie l'erreur cannot find ex.so alors qu'il est bien présent dans le reperoire indiqué.
Je ne vois pas quoi faire de plus, on me parle de faire un makefile mais je ne vois pas l'interet pour compiler un seul fichier main.c
si vous pouvez m'aider ...
d'avance merci
Hola señor!
alors dans le man de gcc, je vois ceci:
Pourrais-tu tester avec cette option et voir ce que ça donne?Code:
2
3-YP,répertoires Rechercher les bibliothèques spécifiées avec -l dans les répertoires répertoires, et aucun autre.
Bonjour,
Quelle version de gcc utilises-tu, avec quel linker ?
Bonjour et merci de vos reponses
Ma version de gcc est la 4.1.2 20070626 (redhat 4.1.2-13)
Ma version de ld est 2.17.50.0.3-6 200601715
Et l'option -YP n'est pas reconnue par ce gcc.
Je suis sous fedora 6 (je n'ai pas trop le choix).
Vous pensez que les versions de gcc sont peut être trop anciennes ??
En tout ca le .so est bien là et ld ne le trouve pas !
Ca fait longtemps que j'ai plus compilé un programme C mais il me semble me souvenir que l'option "-ltoto" n'est qu'un raccourci signifiant "/usr/lib/libtoto.a" (préfixe "/usr/lib" pouvant être modifié avec -L). Donc en écrivant "-Lrep -lex.so", le compilo cherche "rep/libex.so.a"Citation:
Envoyé par nicoesenlamierda
Tente gcc main.c ex.so -o main.exe
Il faut bien specifier la librairie avec -l et le path 'non standard' avec -L.
Mais comme expliqué ci-dessus le linker ajoute un préfixe et un suffixe au nom de la lib tu dois donc faire ainsi :
x renomer ex.so en libex.so
x appeler la compilation avec gcc main.c -o main.exe -L /rep/ -l ex
Bien vu les gars !
C'etait bien ça -l<nom_de_la_librairie>
Merci a tous pour votre aide
Ca marche mais ce n'est pas nécessaire car en faisantCitation:
Envoyé par bizulk
gcc main.c rep/ex.so -o main.exe
ça marche aussi (j'ai testé aujourd'hui) et ça ne nécessite pas de modifier le nom de la librairie.
Je suis d'accord mais en principe on fait ainsi pour les fichiers objets générés pendant la compilation et on explicite les librairies avec l'opion -l, c'est plus clair dans un makefile.
Ah oui je vois. Nos propres librairies sont juste liées par leur nom et les librairies publiques sont liées avec "-l". Mais n'inverses-tu pas la cause et la conséquence ? C'est parce que les librairies publiques se nomment toutes "libmachin.so" qu'on peut les lier avec "-l" et de fait, qu'elles sont liées par "-l". Ce n'est pas parce qu'elles sont publiques...Citation:
Envoyé par bizulk
Bon de toute façon c'était juste pour parler. Le principal est que nicoesenlamierda ait compris comment intégrer une librairie dans son exe. Mais pensera-t-il au LD_LIBRARY_PATH ??? ;)
Librairie publique ou privée c'est ne pas le problème pour moi. Oui tu peux créer ta librairie statique en lui donnant un nom arbitraire, mais par 'convention' une librairie est crée en lui donnant un prefixe 'lib' et un suffixe .a/so pourqu'on puisse facilement la reconnaître et la paramétrer dans une IDE du type eclipse/CDT.
Pour le reste il faut effectivement qu'il configure l'environnement conformément à l'installation de cette lib.
++