Donc comment changer le chemin de recherche de ld en tant que lieur ?
Donc comment changer le chemin de recherche de ld en tant que lieur ?
Donc comment changer le chemin de recherche de ld en tant que lieur ?
In article <41a8826a$0$27321$, matlerouge wrote:
Donc comment changer le chemin de recherche de ld en tant que lieur ?
Je n'ai pas la réponse sous mon chapeau, mais il me semble que ce point
est traité dans la documentation linux from scratch.
In article <41a8826a$0$27321$626a14ce@news.free.fr>, matlerouge wrote:
Donc comment changer le chemin de recherche de ld en tant que lieur ?
Je n'ai pas la réponse sous mon chapeau, mais il me semble que ce point
est traité dans la documentation linux from scratch.
In article <41a8826a$0$27321$, matlerouge wrote:
Donc comment changer le chemin de recherche de ld en tant que lieur ?
Je n'ai pas la réponse sous mon chapeau, mais il me semble que ce point
est traité dans la documentation linux from scratch.
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 ?
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 ?
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 ?
5. For a native linker, the contents of the environment
variable "LD_LIBRARY_PATH".
8. For a native linker on an ELF system, if
the file /etc/ld.so.conf exists, the list of directories
found in that file.
5. For a native linker, the contents of the environment
variable "LD_LIBRARY_PATH".
8. For a native linker on an ELF system, if
the file /etc/ld.so.conf exists, the list of directories
found in that file.
5. For a native linker, the contents of the environment
variable "LD_LIBRARY_PATH".
8. For a native linker on an ELF system, if
the file /etc/ld.so.conf exists, the list of directories
found in that file.
Pour les librairies static (.a), la recherche est plus simple puisque ld
ne fait que les points 4, 5 et 7.
Pour les librairies static (.a), la recherche est plus simple puisque ld
ne fait que les points 4, 5 et 7.
Pour les librairies static (.a), la recherche est plus simple puisque ld
ne fait que les points 4, 5 et 7.
On Sat, 27 Nov 2004 13:37:37 +0000, manuel viet wrote:In article <41a8826a$0$27321$, matlerouge wrote:
Donc comment changer le chemin de recherche de ld en tant que lieur ?
Je n'ai pas la réponse sous mon chapeau, mais il me semble que ce point
est traité dans la documentation linux from scratch.
et de façon très explicite dans le man...
[page de manuel]
Pour les librairies static (.a), la recherche est plus simple puisque ld
ne fait que les points 4, 5 et 7.
On Sat, 27 Nov 2004 13:37:37 +0000, manuel viet wrote:
In article <41a8826a$0$27321$626a14ce@news.free.fr>, matlerouge wrote:
Donc comment changer le chemin de recherche de ld en tant que lieur ?
Je n'ai pas la réponse sous mon chapeau, mais il me semble que ce point
est traité dans la documentation linux from scratch.
et de façon très explicite dans le man...
[page de manuel]
Pour les librairies static (.a), la recherche est plus simple puisque ld
ne fait que les points 4, 5 et 7.
On Sat, 27 Nov 2004 13:37:37 +0000, manuel viet wrote:In article <41a8826a$0$27321$, matlerouge wrote:
Donc comment changer le chemin de recherche de ld en tant que lieur ?
Je n'ai pas la réponse sous mon chapeau, mais il me semble que ce point
est traité dans la documentation linux from scratch.
et de façon très explicite dans le man...
[page de manuel]
Pour les librairies static (.a), la recherche est plus simple puisque ld
ne fait que les points 4, 5 et 7.
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,
les autres points concernent la recherche des
bibliothèques partagées lors de l'exécution du binaire (mais dépendent
parfois des options ou variables utilisées lors de la compilation).
Pour fixer les idées, si on compile ainsi :
ld -o foo -rpath /opt/foo/lib $(OBJECTS) -L../bar -lbar
alors ld va chercher soit libbar.a soit libbar.a dans ../bar, mais à
l'exécution, les bibliothèques partagées seront cherchées dans /opt/foo/lib.
no_spam wrote in message <pan.2004.11.27.13.57.28.641287@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,
les autres points concernent la recherche des
bibliothèques partagées lors de l'exécution du binaire (mais dépendent
parfois des options ou variables utilisées lors de la compilation).
Pour fixer les idées, si on compile ainsi :
ld -o foo -rpath /opt/foo/lib $(OBJECTS) -L../bar -lbar
alors ld va chercher soit libbar.a soit libbar.a dans ../bar, mais à
l'exécution, les bibliothèques partagées seront cherchées dans /opt/foo/lib.
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,
les autres points concernent la recherche des
bibliothèques partagées lors de l'exécution du binaire (mais dépendent
parfois des options ou variables utilisées lors de la compilation).
Pour fixer les idées, si on compile ainsi :
ld -o foo -rpath /opt/foo/lib $(OBJECTS) -L../bar -lbar
alors ld va chercher soit libbar.a soit libbar.a dans ../bar, mais à
l'exécution, les bibliothèques partagées seront cherchées dans /opt/foo/lib.
(...)
Compiler le compilateur gcc est un cas à part.
C'est un peu comme écrire un système d'exploitation sur une machine
sans système d'exploitation mais qui doit fonctionner quand même!
Ce n'est pas forcément le bon gros programme à compiler pour s'amuser
ou apprendre.
Dans mes souvenirs (lontains!), gcc se compilait de manière récursive:
1- Compilation de gcc(n+1) avec gcc(n);
2- Verification du fonctionnement de gcc(n+1);
3- Installation de gcc(n+1) (Avec sauvegarde de gcc(n), évidemment!);
4- Compilation de gcc(n+1) avec gcc(n+1) fraichement installé.
5- Refaire point 2 puis point 3
6- Recommencer les points 4, 2 puis 3.
(...)
Compiler le compilateur gcc est un cas à part.
C'est un peu comme écrire un système d'exploitation sur une machine
sans système d'exploitation mais qui doit fonctionner quand même!
Ce n'est pas forcément le bon gros programme à compiler pour s'amuser
ou apprendre.
Dans mes souvenirs (lontains!), gcc se compilait de manière récursive:
1- Compilation de gcc(n+1) avec gcc(n);
2- Verification du fonctionnement de gcc(n+1);
3- Installation de gcc(n+1) (Avec sauvegarde de gcc(n), évidemment!);
4- Compilation de gcc(n+1) avec gcc(n+1) fraichement installé.
5- Refaire point 2 puis point 3
6- Recommencer les points 4, 2 puis 3.
(...)
Compiler le compilateur gcc est un cas à part.
C'est un peu comme écrire un système d'exploitation sur une machine
sans système d'exploitation mais qui doit fonctionner quand même!
Ce n'est pas forcément le bon gros programme à compiler pour s'amuser
ou apprendre.
Dans mes souvenirs (lontains!), gcc se compilait de manière récursive:
1- Compilation de gcc(n+1) avec gcc(n);
2- Verification du fonctionnement de gcc(n+1);
3- Installation de gcc(n+1) (Avec sauvegarde de gcc(n), évidemment!);
4- Compilation de gcc(n+1) avec gcc(n+1) fraichement installé.
5- Refaire point 2 puis point 3
6- Recommencer les points 4, 2 puis 3.
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...
Ils sont aussi utilisé par ld au moment de la compil:
il vérifie qu'il
peut bien résoudre tous les symboles des libraries partagées au moment
du link.
Le fonctionnement du linker dynamique est différent et est indépendant
des options du link lors de la compilation.
ld -o foo -rpath /opt/foo/lib $(OBJECTS) -L../bar -lbar
Il va aussi chercher les libs dynamiques au moment du link dans
/opt/foo/lib.
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...
Ils sont aussi utilisé par ld au moment de la compil:
il vérifie qu'il
peut bien résoudre tous les symboles des libraries partagées au moment
du link.
Le fonctionnement du linker dynamique est différent et est indépendant
des options du link lors de la compilation.
ld -o foo -rpath /opt/foo/lib $(OBJECTS) -L../bar -lbar
Il va aussi chercher les libs dynamiques au moment du link dans
/opt/foo/lib.
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...
Ils sont aussi utilisé par ld au moment de la compil:
il vérifie qu'il
peut bien résoudre tous les symboles des libraries partagées au moment
du link.
Le fonctionnement du linker dynamique est différent et est indépendant
des options du link lors de la compilation.
ld -o foo -rpath /opt/foo/lib $(OBJECTS) -L../bar -lbar
Il va aussi chercher les libs dynamiques au moment du link dans
/opt/foo/lib.
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.
peut bien résoudre tous les symboles des libraries partagées au moment
du link.
Oui, mais ce n'est pas de ça qu'il est question.
Le fonctionnement du linker dynamique est différent et est indépendant
des options du link lors de la compilation.
Stricto sensu, c'est vrai. Mais les options de liaison lors de la
compilation influent sur les options présentes dans le binaire, qui à leur
tour influent sur le fonctionnement du chargeur dynamique.
ld -o foo -rpath /opt/foo/lib $(OBJECTS) -L../bar -lbar
Il va aussi chercher les libs dynamiques au moment du link dans
/opt/foo/lib.
Non, il ne le fait pas. Tu peux essayer.
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.
peut bien résoudre tous les symboles des libraries partagées au moment
du link.
Oui, mais ce n'est pas de ça qu'il est question.
Le fonctionnement du linker dynamique est différent et est indépendant
des options du link lors de la compilation.
Stricto sensu, c'est vrai. Mais les options de liaison lors de la
compilation influent sur les options présentes dans le binaire, qui à leur
tour influent sur le fonctionnement du chargeur dynamique.
ld -o foo -rpath /opt/foo/lib $(OBJECTS) -L../bar -lbar
Il va aussi chercher les libs dynamiques au moment du link dans
/opt/foo/lib.
Non, il ne le fait pas. Tu peux essayer.
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.
peut bien résoudre tous les symboles des libraries partagées au moment
du link.
Oui, mais ce n'est pas de ça qu'il est question.
Le fonctionnement du linker dynamique est différent et est indépendant
des options du link lors de la compilation.
Stricto sensu, c'est vrai. Mais les options de liaison lors de la
compilation influent sur les options présentes dans le binaire, qui à leur
tour influent sur le fonctionnement du chargeur dynamique.
ld -o foo -rpath /opt/foo/lib $(OBJECTS) -L../bar -lbar
Il va aussi chercher les libs dynamiques au moment du link dans
/opt/foo/lib.
Non, il ne le fait pas. Tu peux essayer.