Forum Programmation.autre gcc ne trouve pas ma bibliothèque ...

Posté par  (site web personnel) .
Étiquettes :
0
16
oct.
2006
Bonjour,

J'ai un petit problème ... gcc n'arrive pas à trouver une bibliothèque et je ne comprend pas pourquoi.

Ce qui se passe c'est que dans mon répertoire personnel, j'ai un dossier .local qui contient un sous-dossier lib bin share src etc.
dans mon dossier ~/.local/lib j'ai des bibliothèques installées.

Du coup, je me débrouille pour avoir déinie les variables d'environnement :
- PATH : pour qu'il trouve les exécutables
- LD_LIBRARY_PATH : pour que mes libs soient trouvées à l'exécution
- C_INCLUDE_PATH : pour trouver mes fichiers headers
- LIBRARY_PATH : pour trouver les libs à la compilation

Le problème c'est que LIBRARY_PATH ne joue pas son rôle ... pourtant dans man gcc :
The value of LIBRARY_PATH is a colon-separated list of directories, much like PATH. When configured as a native compiler, GCC tries the directories thus specified when searching for special linker files, if it cann’t find them using GCC_EXEC_PREFIX. Linking using GCC also uses these directories when searching for ordinary libraries for the -l option (but directories specified with -L come first).


De fait, j'ai un petit programme très simple qui utilise une fonction de la bibliothèque lua qui n'est installée que dans ~/.local. Et lorsque je compile :

$ gcc -v -llua hello.c
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
/usr/lib/gcc/i486-linux-gnu/4.1.2/cc1 -quiet -v hello.c -quiet -dumpbase hello.c -mtune=generic -auxbase hello -version -fstack-protector -fstack-protector -o /tmp/cc7vKVa5.s
ignoring duplicate directory "/home/mildred/.local/include"
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring duplicate directory "/usr/local/include"
ignoring nonexistent directory "/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
ignoring duplicate directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
/home/mildred/.local/include
/usr/local/include
/usr/include
/usr/lib/gcc/i486-linux-gnu/4.1.2/include
End of search list.
GNU C version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) (i486-linux-gnu)
compiled by GNU C version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64508
Compiler executable checksum: 9dfacd053f7c05ab266630071b88af60
as -V -Qy -o /tmp/ccAKkh33.o /tmp/cc7vKVa5.s
GNU assembler version 2.17 (i486-linux-gnu) using BFD version 2.17 Debian GNU/Linux
/usr/lib/gcc/i486-linux-gnu/4.1.2/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/../lib/crt1.o /usr/lib/../lib/crti.o /usr/lib/gcc/i486-linux-gnu/4.1.2/crtbegin.o -L/home/mildred/.local/lib/../lib -L/home/mildred/.local/lib/../lib -L/usr/local/lib/../lib -L/usr/lib/../lib -L/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.1.2 -L/usr/lib/gcc/i486-linux-gnu/4.1.2 -L/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -llua /tmp/ccAKkh33.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i486-linux-gnu/4.1.2/crtend.o /usr/lib/../lib/crtn.o
/tmp/ccAKkh33.o: In function `main':
hello.c:(.text+0x12): undefined reference to `lua_open'
collect2: ld returned 1 exit status

$ test -f ~/.local/lib/liblua.a && echo EXISTS
EXISTS


Ce qui est étrange, c'est que le dossier contenant ma lib fait partie de la ligne de commande de collect2 ... Du coup, je ne comprend pas comment gcc échoue à lier mon programme avec ma lib :(

Savez vous pourquoi ?
Merci de votre réponse.

--
PS: j'essaie en fait d'utiliser autoconf pour détecter la lib avec AC_SEARCH_LIBS([lua_open], [lua]) ... du coup je n'ai pas trop de maîtrise sur la ligne de commande utilisée pour faire le test.
Merci

Mildred
  • # Doute

    Posté par  (site web personnel) . Évalué à 3.

    Est-ce normal que tu aie /home/mildred/.local/lib/../lib ? gcc accepte-t-il le .. ?

    Sinon, en général à la compitaion, on ajoute simplement le flag -L a gcc pour qu'il utilise les libs qu'on veut.
    • [^] # Re: Doute

      Posté par  (site web personnel) . Évalué à 2.

      le . ne devrait pas poser de problèmes normalement ... cela correspond exactement au même dossier.

      Et le problème du flag -L c'est que je ne peux pas y toucher,j c'est autoconf qui gère la ligne de commande gcc :(

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.