/usr/bin/ld: skipping incompatible /usr/lib/../lib/libc.so when
searching for -lc
(...)
/usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc
/usr/bin/ld: cannot find -lc
En fait je fais du gros bricolage, mais bon.
J'ai donc mis la bonne libc dans un repertoire /libtmp (car je ne veux
pas corrompre l'autre libc : enfait je compile une nouvelle version de
gcc avec une version de gcc qui est pas faite pour mon systeme)
Je pensais qu'en configurant ld.so.conf en lui rajoutant /libtmp, puis
un ldconfig suffirais a faire chercher ld dans /libtmp. Mais je me suis
trompé : ld ne cherche toujours pas dans /libtmp.
Apparement en modifiant ld.so.conf on ne change que le repertoire de
recherche de lib dynamique a l'execution du prog c'est ca ?
Donc comment changer le chemin de recherche de ld en tant que lieur ?
On Sat, 27 Nov 2004 18:42:46 +0100, no_spam wrote:
On Sat, 27 Nov 2004 16:31:34 +0000, Nicolas George wrote:
no_spam wrote in message :
Pour les librairies static (.a), la recherche est plus simple puisque ld ne fait que les points 4, 5 et 7. Tu dis des bêtises : la différence ne se fait pas sur la dualité
statique/partagées, mais sur la dualité compilation/exécution. Les points 4 et 7 concernent la recherche des bibliothèques, tant statiques que partagées à la production du binaire, C'est exactement ce que je dit...
Non. D'ailleurs je laisse la citation, pour que tout le monde puisse s'en rendre compte : tu prétends qu'il y a une différence entre le cas statique et le cas partagé.
Ils sont aussi utilisé par ld au moment de la compil:
Non, cf. plus bas.
Si tu développait tous les jours par exemple en cross-developpement (donc en utilisant pas les libraries systèmes), tu te rendrais vite compte que de c'est délirant... Donc, non seulement ils sont utilisé par ld, mais en plus ils sont ___indispensables___ pour que ld fonctionne !
D'ailleurs relit le man, notement la partie que j'ai publiée, ça commence par: "le linker utilise les chemins de recherche suivant pour localiser les libraries partagées requises" suivent les 8 points. Ce n'est pas assez explicite ?
On Sat, 27 Nov 2004 18:42:46 +0100, no_spam wrote:
On Sat, 27 Nov 2004 16:31:34 +0000, Nicolas George wrote:
no_spam wrote in message <pan.2004.11.27.15.23.12.175254@magic.fr>:
Pour les librairies static (.a), la recherche est plus simple puisque ld
ne fait que les points 4, 5 et 7.
Tu dis des bêtises : la différence ne se fait pas sur la dualité
statique/partagées, mais sur la dualité compilation/exécution. Les points 4
et 7 concernent la recherche des bibliothèques, tant statiques que partagées
à la production du binaire,
C'est exactement ce que je dit...
Non. D'ailleurs je laisse la citation, pour que tout le monde puisse s'en
rendre compte : tu prétends qu'il y a une différence entre le cas statique
et le cas partagé.
Ils sont aussi utilisé par ld au moment de la compil:
Non, cf. plus bas.
Si tu développait tous les jours par exemple en cross-developpement (donc
en utilisant pas les libraries systèmes), tu te rendrais vite compte que
de c'est délirant...
Donc, non seulement ils sont utilisé par ld, mais en plus ils sont
___indispensables___ pour que ld fonctionne !
D'ailleurs relit le man, notement la partie que j'ai publiée,
ça commence par:
"le linker utilise les chemins de recherche suivant pour localiser
les libraries partagées requises"
suivent les 8 points.
Ce n'est pas assez explicite ?
On Sat, 27 Nov 2004 18:42:46 +0100, no_spam wrote:
On Sat, 27 Nov 2004 16:31:34 +0000, Nicolas George wrote:
no_spam wrote in message :
Pour les librairies static (.a), la recherche est plus simple puisque ld ne fait que les points 4, 5 et 7. Tu dis des bêtises : la différence ne se fait pas sur la dualité
statique/partagées, mais sur la dualité compilation/exécution. Les points 4 et 7 concernent la recherche des bibliothèques, tant statiques que partagées à la production du binaire, C'est exactement ce que je dit...
Non. D'ailleurs je laisse la citation, pour que tout le monde puisse s'en rendre compte : tu prétends qu'il y a une différence entre le cas statique et le cas partagé.
Ils sont aussi utilisé par ld au moment de la compil:
Non, cf. plus bas.
Si tu développait tous les jours par exemple en cross-developpement (donc en utilisant pas les libraries systèmes), tu te rendrais vite compte que de c'est délirant... Donc, non seulement ils sont utilisé par ld, mais en plus ils sont ___indispensables___ pour que ld fonctionne !
D'ailleurs relit le man, notement la partie que j'ai publiée, ça commence par: "le linker utilise les chemins de recherche suivant pour localiser les libraries partagées requises" suivent les 8 points. Ce n'est pas assez explicite ?
Nicolas George
no_spam wrote in message :
Il est bien obligé, sinon explique moi comment il résoud les symboles ?
En allant chercher les bibliothèques dans les chemins indiqués par -L.
Dis, quand je te dis que tu peux essayer, c'est que tu peux essayer, et te rendre compte de ton erreur.
Voici un exemple :
ssecem /tmp $ ls -l run-time build-time build-time: total 0 lrwxrwxrwx 1 cigaes cigaes 28 Nov 27 19:28 libfrobnicate.so -> ../run-time/libfrobnicate.so*
run-time: total 8 -rwxr-xr-x 1 cigaes cigaes 6584 Nov 27 19:27 libfrobnicate.so*
On voir donc que j'ai /tmp/run-time et /tmp/build-time, avec le même .so dedans.
ssecem /tmp $ nm -D build-time/libfrobnicate.so <snip> 00000644 T frobnicate
Ce libfrobnicate.so définit donc la fonction frobnicate.
Maintenant, essayons de le lier. Comme c'est trop pénible d'écrire toutes les options de ld pour créer un exécutable dynamique qui marche, je vais le faire avec gcc.
Premier cas : je ne précise aucun répertoire.
ssecem /tmp $ gcc demo.o -lfrobnicate /usr/bin/ld: cannot find -lfrobnicate collect2: ld returned 1 exit status
Sans surprise, ça échoue en ne trouvant pas libfrobnicate.
Deuxième cas : je ne précise qu'un -rpath :
ssecem /tmp $ gcc -Wl,-rpath,/tmp/run-time demo.o -lfrobnicate /usr/bin/ld: cannot find -lfrobnicate collect2: ld returned 1 exit status
Ça fonctionne, et l'exécutable est valide. Un examen plus attentif avec strace aurait montré que ld ne va chercher dans ce cas que dans /tmp/build-time.
En résumé, apprends que ld, lors de la construction de l'exécutable, ne tient pas compte des options -rpath et similaires.
no_spam wrote in message <pan.2004.11.27.17.42.45.619154@magic.fr>:
Il est bien obligé, sinon explique moi comment il résoud les symboles ?
En allant chercher les bibliothèques dans les chemins indiqués par -L.
Dis, quand je te dis que tu peux essayer, c'est que tu peux essayer, et te
rendre compte de ton erreur.
Voici un exemple :
ssecem /tmp $ ls -l run-time build-time
build-time:
total 0
lrwxrwxrwx 1 cigaes cigaes 28 Nov 27 19:28 libfrobnicate.so -> ../run-time/libfrobnicate.so*
run-time:
total 8
-rwxr-xr-x 1 cigaes cigaes 6584 Nov 27 19:27 libfrobnicate.so*
On voir donc que j'ai /tmp/run-time et /tmp/build-time, avec le même .so
dedans.
ssecem /tmp $ nm -D build-time/libfrobnicate.so
<snip>
00000644 T frobnicate
Ce libfrobnicate.so définit donc la fonction frobnicate.
Maintenant, essayons de le lier. Comme c'est trop pénible d'écrire toutes
les options de ld pour créer un exécutable dynamique qui marche, je vais le
faire avec gcc.
Premier cas : je ne précise aucun répertoire.
ssecem /tmp $ gcc demo.o -lfrobnicate
/usr/bin/ld: cannot find -lfrobnicate
collect2: ld returned 1 exit status
Sans surprise, ça échoue en ne trouvant pas libfrobnicate.
Deuxième cas : je ne précise qu'un -rpath :
ssecem /tmp $ gcc -Wl,-rpath,/tmp/run-time demo.o -lfrobnicate
/usr/bin/ld: cannot find -lfrobnicate
collect2: ld returned 1 exit status
Ça fonctionne, et l'exécutable est valide. Un examen plus attentif avec
strace aurait montré que ld ne va chercher dans ce cas que dans
/tmp/build-time.
En résumé, apprends que ld, lors de la construction de l'exécutable, ne
tient pas compte des options -rpath et similaires.
Maintenant, essayons de le lier. Comme c'est trop pénible d'écrire toutes les options de ld pour créer un exécutable dynamique qui marche, je vais le faire avec gcc.
Premier cas : je ne précise aucun répertoire.
ssecem /tmp $ gcc demo.o -lfrobnicate /usr/bin/ld: cannot find -lfrobnicate collect2: ld returned 1 exit status
Sans surprise, ça échoue en ne trouvant pas libfrobnicate.
Deuxième cas : je ne précise qu'un -rpath :
ssecem /tmp $ gcc -Wl,-rpath,/tmp/run-time demo.o -lfrobnicate /usr/bin/ld: cannot find -lfrobnicate collect2: ld returned 1 exit status
Ça fonctionne, et l'exécutable est valide. Un examen plus attentif avec strace aurait montré que ld ne va chercher dans ce cas que dans /tmp/build-time.
En résumé, apprends que ld, lors de la construction de l'exécutable, ne tient pas compte des options -rpath et similaires.
no_spam
On Sat, 27 Nov 2004 18:43:45 +0000, Nicolas George wrote:
no_spam wrote in message :
Il est bien obligé, sinon explique moi comment il résoud les symboles ?
En allant chercher les bibliothèques dans les chemins indiqués par -L.
Dis, quand je te dis que tu peux essayer, c'est que tu peux essayer, et te rendre compte de ton erreur. [...]
En résumé, apprends que ld, lors de la construction de l'exécutable, ne tient pas compte des options -rpath et similaires.
C'est donc un bug, puisque c'est contraire à ce que dit la spec de ld... "All -rpath arguments are concatenated and passed to the runtime linker, which uses them to locate shared objects at runtime." C'est bien ce que tu dis. Ce qui est marqué juste après: "The -rpath option is also used when locating shared objects which are needed by shared objects explicitly included in the link" Donc, d'après ta démonstration, il faut en conclure que GNU ld est buggé...
On Sat, 27 Nov 2004 18:43:45 +0000, Nicolas George wrote:
no_spam wrote in message <pan.2004.11.27.17.42.45.619154@magic.fr>:
Il est bien obligé, sinon explique moi comment il résoud les symboles ?
En allant chercher les bibliothèques dans les chemins indiqués par -L.
Dis, quand je te dis que tu peux essayer, c'est que tu peux essayer, et te
rendre compte de ton erreur.
[...]
En résumé, apprends que ld, lors de la construction de l'exécutable, ne
tient pas compte des options -rpath et similaires.
C'est donc un bug, puisque c'est contraire à ce que dit la spec de ld...
"All -rpath arguments are concatenated and passed to the runtime linker,
which uses them to locate shared objects at runtime."
C'est bien ce que tu dis.
Ce qui est marqué juste après:
"The -rpath option is also used when locating shared objects which are
needed by shared objects explicitly included in the link"
Donc, d'après ta démonstration, il faut en conclure que GNU ld est
buggé...
On Sat, 27 Nov 2004 18:43:45 +0000, Nicolas George wrote:
no_spam wrote in message :
Il est bien obligé, sinon explique moi comment il résoud les symboles ?
En allant chercher les bibliothèques dans les chemins indiqués par -L.
Dis, quand je te dis que tu peux essayer, c'est que tu peux essayer, et te rendre compte de ton erreur. [...]
En résumé, apprends que ld, lors de la construction de l'exécutable, ne tient pas compte des options -rpath et similaires.
C'est donc un bug, puisque c'est contraire à ce que dit la spec de ld... "All -rpath arguments are concatenated and passed to the runtime linker, which uses them to locate shared objects at runtime." C'est bien ce que tu dis. Ce qui est marqué juste après: "The -rpath option is also used when locating shared objects which are needed by shared objects explicitly included in the link" Donc, d'après ta démonstration, il faut en conclure que GNU ld est buggé...
Nicolas George
no_spam wrote in message :
C'est donc un bug, puisque c'est contraire à ce que dit la spec de ld...
Je ne la lis pas de la même manière que toi.
"All -rpath arguments are concatenated and passed to the runtime linker, which uses them to locate shared objects at runtime." C'est bien ce que tu dis.
« at runtime », on est d'accord.
Ce qui est marqué juste après: "The -rpath option is also used when locating shared objects which are needed by shared objects explicitly included in the link"
Ça, je lis ça comme : si foo (binaire) a libbar.so comme NEEDED, et si libbar.so a libqux.so comme NEEDED, le RPATH de foo va être utilisé pour localiser lobqux.so. Eu runtime. C'est vaguement en contradiction avec la spec ELF, il me semble, mais similaire à ce que fait Solaris (mais pas ce que fait FreeBSD).
Cette phrase est assez obscure, mais il y a un point qui est clair : si on écrit -lbar, cette phrase ne décrit pas comment est trouvé libbar.so mais les dépendances de libbar.so.
Donc, d'après ta démonstration, il faut en conclure que GNU ld est buggé...
Non. Sa doc est incompréhensible si on ne sait pas déjà ce qu'il faut y comprendre, c'est très clairement un problème, mais le comportement est le bon car :
- il est similaire à celui des éditeurs de liens d'autres Unix ;
- il risque moins de provoquer des incompatibilité quand on essaie de lier dans un environnement différent de celui de l'exécution (compilation croisée ou installation des bibliothèques pas encore réalisée).
no_spam wrote in message <pan.2004.11.28.12.44.00.818246@magic.fr>:
C'est donc un bug, puisque c'est contraire à ce que dit la spec de ld...
Je ne la lis pas de la même manière que toi.
"All -rpath arguments are concatenated and passed to the runtime linker,
which uses them to locate shared objects at runtime."
C'est bien ce que tu dis.
« at runtime », on est d'accord.
Ce qui est marqué juste après:
"The -rpath option is also used when locating shared objects which are
needed by shared objects explicitly included in the link"
Ça, je lis ça comme : si foo (binaire) a libbar.so comme NEEDED, et si
libbar.so a libqux.so comme NEEDED, le RPATH de foo va être utilisé pour
localiser lobqux.so. Eu runtime. C'est vaguement en contradiction avec la
spec ELF, il me semble, mais similaire à ce que fait Solaris (mais pas ce
que fait FreeBSD).
Cette phrase est assez obscure, mais il y a un point qui est clair : si on
écrit -lbar, cette phrase ne décrit pas comment est trouvé libbar.so mais
les dépendances de libbar.so.
Donc, d'après ta démonstration, il faut en conclure que GNU ld est
buggé...
Non. Sa doc est incompréhensible si on ne sait pas déjà ce qu'il faut y
comprendre, c'est très clairement un problème, mais le comportement est le
bon car :
- il est similaire à celui des éditeurs de liens d'autres Unix ;
- il risque moins de provoquer des incompatibilité quand on essaie de lier
dans un environnement différent de celui de l'exécution (compilation
croisée ou installation des bibliothèques pas encore réalisée).
C'est donc un bug, puisque c'est contraire à ce que dit la spec de ld...
Je ne la lis pas de la même manière que toi.
"All -rpath arguments are concatenated and passed to the runtime linker, which uses them to locate shared objects at runtime." C'est bien ce que tu dis.
« at runtime », on est d'accord.
Ce qui est marqué juste après: "The -rpath option is also used when locating shared objects which are needed by shared objects explicitly included in the link"
Ça, je lis ça comme : si foo (binaire) a libbar.so comme NEEDED, et si libbar.so a libqux.so comme NEEDED, le RPATH de foo va être utilisé pour localiser lobqux.so. Eu runtime. C'est vaguement en contradiction avec la spec ELF, il me semble, mais similaire à ce que fait Solaris (mais pas ce que fait FreeBSD).
Cette phrase est assez obscure, mais il y a un point qui est clair : si on écrit -lbar, cette phrase ne décrit pas comment est trouvé libbar.so mais les dépendances de libbar.so.
Donc, d'après ta démonstration, il faut en conclure que GNU ld est buggé...
Non. Sa doc est incompréhensible si on ne sait pas déjà ce qu'il faut y comprendre, c'est très clairement un problème, mais le comportement est le bon car :
- il est similaire à celui des éditeurs de liens d'autres Unix ;
- il risque moins de provoquer des incompatibilité quand on essaie de lier dans un environnement différent de celui de l'exécution (compilation croisée ou installation des bibliothèques pas encore réalisée).
