Comment, en général, le code binaire de la bibliothèque standard apparait-il
dans le système de fichier ? sous la forme d'un seul (et assez gros ?) fichier
ou en plusieurs fichiers, chacun gérant les fonctions de chaque en-tête
(<stdlib.h>, <stdio.h>, etc), en supposant qu'il s'agisse de fichiers (je sais
que ce n'est pas nécessaire).
D'autre part, toujours en général, la bibliothèque standard est-elle statique ou
dynamique ? Sous Windows avec Mingw, il me semble que c'est un fichier
d'extension .a . Sous Linux et gcc, qu'en est-il ? De quel(s) fichier(s) (nom,
extension et répertoire) s'agit-il ?
Meme sous Linux, c'est plus tres vrai, tout ca. Les binutils recents introduisent des "linker scripts" qui permettent de faire des trucs assez tordus cote gestion des bibliotheques.
Ces jours-ci, la libc sous linux, c'est un blob que l'editeur de liens connait, et auquel il se refere quand il veut faire une edition de liens.
Par exemple, sur un Linux auquel j'ai acces, voici /usr/lib/libc.so:
/* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf32-i386) GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld-linux.so.2 ) )
et les raisons pour lesquelles certains bouts sont dans libc.so.6, d'autres dans libc_nonshared.a, et enfin quelques morceaux qui necessitent ld-linux.so.2, eh bien, si vous ne faites pas du systeme, en general vous ne voulez pas savoir...
Meme sous Linux, c'est plus tres vrai, tout ca.
Les binutils recents introduisent des "linker scripts" qui permettent
de faire des trucs assez tordus cote gestion des bibliotheques.
Ces jours-ci, la libc sous linux, c'est un blob que l'editeur de liens
connait, et auquel il se refere quand il veut faire une edition de liens.
Par exemple, sur un Linux auquel j'ai acces, voici /usr/lib/libc.so:
/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld-linux.so.2 ) )
et les raisons pour lesquelles certains bouts sont dans
libc.so.6, d'autres dans libc_nonshared.a, et enfin quelques morceaux
qui necessitent ld-linux.so.2, eh bien, si vous ne faites pas du systeme,
en general vous ne voulez pas savoir...
Meme sous Linux, c'est plus tres vrai, tout ca. Les binutils recents introduisent des "linker scripts" qui permettent de faire des trucs assez tordus cote gestion des bibliotheques.
Ces jours-ci, la libc sous linux, c'est un blob que l'editeur de liens connait, et auquel il se refere quand il veut faire une edition de liens.
Par exemple, sur un Linux auquel j'ai acces, voici /usr/lib/libc.so:
/* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf32-i386) GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld-linux.so.2 ) )
et les raisons pour lesquelles certains bouts sont dans libc.so.6, d'autres dans libc_nonshared.a, et enfin quelques morceaux qui necessitent ld-linux.so.2, eh bien, si vous ne faites pas du systeme, en general vous ne voulez pas savoir...
espie
In article <4986f0b4$0$10259$, candide wrote:
comment fait-on sous Linux pour fondre deux fichiers objets en un seul : toto1.o +toto2.o = toto.o ? C'est possible ? (Naturellement, j'ai parcouru longuement le manuel de gcc.)
Oui, et non. Ca va dependre de ce que tu veux. - bibliotheque au sens classique: on ne melange rien, on fait juste une archive (mettons libtruc.a) qui contiendra toto1.o et toto2.o. Si tu fais ton edition de liens avec -ltruc, l'editeur de liens prendre toto1.o et ou toto2.o dans le resultat. - bibliotheque au sens bibliotheque dynamique. Pas beaucoup d'autre rapport que le nom. Ces bibliotheques sont en fait des "objects chargeables dynamiquement". Ca s'obtient en: * fabriquant des fichiers objets susceptibles de faire partie d'un tel objet. (souvent -fpic ou -fPIC, dependant du processeur). * faisant une edition de liens finale pour fabriquer l'objet en question, avec les bonnes incantations (ici, gcc -shared sait faire). Ca va produire autre chose qu'une bete executable (un objet chargeable dynamiquement), et ca permet a l'editions de liens d'etre "partielle" (pas besoin de main, et generalement on peut laisser des symboles pour plus tard). C'est ensuite le boulot de l'editeur de liens dynamique de recoller les morceaux, soit au demarrage du programme si tu as code en dur des objets dynamiques dedans (c'est les "bibliotheques dynamiques" traditionnelles), soit plus tard si tu charges explicitement ces objets un peu apres (a coup de dlopen/dlsym, c'est les "plugin" habituels).
Le point important, c'est qu'il y a effectivement "melange" des divers objets pour une bibliotheque dynamique (tu gardes juste les symboles et pas l'identite des objets) et "simple archivage" pour une bibliotheque statique (tu peux aller rechercher exactement les fichiers que tu veux dans ta bibliotheque).
C'est le modele actuel "classique" sur systeme linux ou Unix (quasiment tous les unix aujourd'hui utilisent du ELF, avec ce modele d'objets dynamiquement chargeables). Pas mal de gens bidouillent avec des extensions: - granularite de la bibliotheque au niveau de la fonction - inter-optimisation entre fichiers objets - systemes de cache plus ou moins sophistiques pour eviter de tout charger/de refaire l'edition de liens dynamique a chaque fois pour des bibliotheques dynamiques.
In article <4986f0b4$0$10259$426a74cc@news.free.fr>,
candide <candide@free.invalid> wrote:
comment fait-on sous Linux pour fondre deux fichiers objets en un seul :
toto1.o +toto2.o = toto.o ? C'est possible ? (Naturellement, j'ai parcouru
longuement le manuel de gcc.)
Oui, et non. Ca va dependre de ce que tu veux.
- bibliotheque au sens classique: on ne melange rien, on fait juste une
archive (mettons libtruc.a) qui contiendra toto1.o et toto2.o. Si tu fais
ton edition de liens avec -ltruc, l'editeur de liens prendre toto1.o et ou
toto2.o dans le resultat.
- bibliotheque au sens bibliotheque dynamique. Pas beaucoup d'autre rapport
que le nom. Ces bibliotheques sont en fait des "objects chargeables
dynamiquement". Ca s'obtient en:
* fabriquant des fichiers objets susceptibles de faire partie d'un tel objet.
(souvent -fpic ou -fPIC, dependant du processeur).
* faisant une edition de liens finale pour fabriquer l'objet en question,
avec les bonnes incantations (ici, gcc -shared sait faire). Ca va produire
autre chose qu'une bete executable (un objet chargeable dynamiquement), et
ca permet a l'editions de liens d'etre "partielle" (pas besoin de main, et
generalement on peut laisser des symboles pour plus tard).
C'est ensuite le boulot de l'editeur de liens dynamique de recoller les
morceaux, soit au demarrage du programme si tu as code en dur des objets
dynamiques dedans (c'est les "bibliotheques dynamiques" traditionnelles),
soit plus tard si tu charges explicitement ces objets un peu apres (a coup
de dlopen/dlsym, c'est les "plugin" habituels).
Le point important, c'est qu'il y a effectivement "melange" des divers objets
pour une bibliotheque dynamique (tu gardes juste les symboles et pas l'identite
des objets) et "simple archivage" pour une bibliotheque statique (tu peux aller
rechercher exactement les fichiers que tu veux dans ta bibliotheque).
C'est le modele actuel "classique" sur systeme linux ou Unix (quasiment tous
les unix aujourd'hui utilisent du ELF, avec ce modele d'objets dynamiquement
chargeables). Pas mal de gens bidouillent avec des extensions:
- granularite de la bibliotheque au niveau de la fonction
- inter-optimisation entre fichiers objets
- systemes de cache plus ou moins sophistiques pour eviter de tout charger/de
refaire l'edition de liens dynamique a chaque fois pour des bibliotheques
dynamiques.
comment fait-on sous Linux pour fondre deux fichiers objets en un seul : toto1.o +toto2.o = toto.o ? C'est possible ? (Naturellement, j'ai parcouru longuement le manuel de gcc.)
Oui, et non. Ca va dependre de ce que tu veux. - bibliotheque au sens classique: on ne melange rien, on fait juste une archive (mettons libtruc.a) qui contiendra toto1.o et toto2.o. Si tu fais ton edition de liens avec -ltruc, l'editeur de liens prendre toto1.o et ou toto2.o dans le resultat. - bibliotheque au sens bibliotheque dynamique. Pas beaucoup d'autre rapport que le nom. Ces bibliotheques sont en fait des "objects chargeables dynamiquement". Ca s'obtient en: * fabriquant des fichiers objets susceptibles de faire partie d'un tel objet. (souvent -fpic ou -fPIC, dependant du processeur). * faisant une edition de liens finale pour fabriquer l'objet en question, avec les bonnes incantations (ici, gcc -shared sait faire). Ca va produire autre chose qu'une bete executable (un objet chargeable dynamiquement), et ca permet a l'editions de liens d'etre "partielle" (pas besoin de main, et generalement on peut laisser des symboles pour plus tard). C'est ensuite le boulot de l'editeur de liens dynamique de recoller les morceaux, soit au demarrage du programme si tu as code en dur des objets dynamiques dedans (c'est les "bibliotheques dynamiques" traditionnelles), soit plus tard si tu charges explicitement ces objets un peu apres (a coup de dlopen/dlsym, c'est les "plugin" habituels).
Le point important, c'est qu'il y a effectivement "melange" des divers objets pour une bibliotheque dynamique (tu gardes juste les symboles et pas l'identite des objets) et "simple archivage" pour une bibliotheque statique (tu peux aller rechercher exactement les fichiers que tu veux dans ta bibliotheque).
C'est le modele actuel "classique" sur systeme linux ou Unix (quasiment tous les unix aujourd'hui utilisent du ELF, avec ce modele d'objets dynamiquement chargeables). Pas mal de gens bidouillent avec des extensions: - granularite de la bibliotheque au niveau de la fonction - inter-optimisation entre fichiers objets - systemes de cache plus ou moins sophistiques pour eviter de tout charger/de refaire l'edition de liens dynamique a chaque fois pour des bibliotheques dynamiques.
Marc
batyann811 wrote:
Chez moi c'est /lib/libc-2.3.5.so. Mais ne t'aventures pas à effacer ou déplacer ce fichier car tu risques d'avoir de gros problèmes. Du genre ne plus pouvoir lancer aucun programme qui serait lié avec cette bibliothèque.
Le fichier qui peut etre supprimé, c'est /usr/lib/libc.so (qui a des chances de venir d'un paquet libc-dev, par exemple), qui est un lien symbolique vers le vrai fichier utilisé a l'exécution.
comment fait-on sous Linux pour fondre deux fichiers objets en un seul : toto1.o +toto2.o = toto.o ? C'est possible ? (Naturellement, j'ai parcouru longuement le manuel de gcc.)
ld -r Mais ce n'est pas une bonne idée, les archives (.a) sont plus adaptées.
batyann811 wrote:
Chez moi c'est /lib/libc-2.3.5.so. Mais ne t'aventures pas à effacer ou
déplacer ce fichier car tu risques d'avoir de gros problèmes. Du genre
ne plus pouvoir lancer aucun programme qui serait lié avec cette
bibliothèque.
Le fichier qui peut etre supprimé, c'est /usr/lib/libc.so (qui a des
chances de venir d'un paquet libc-dev, par exemple), qui est un lien
symbolique vers le vrai fichier utilisé a l'exécution.
comment fait-on sous Linux pour fondre deux fichiers objets en un seul :
toto1.o +toto2.o = toto.o ? C'est possible ? (Naturellement, j'ai parcouru
longuement le manuel de gcc.)
ld -r
Mais ce n'est pas une bonne idée, les archives (.a) sont plus adaptées.
Chez moi c'est /lib/libc-2.3.5.so. Mais ne t'aventures pas à effacer ou déplacer ce fichier car tu risques d'avoir de gros problèmes. Du genre ne plus pouvoir lancer aucun programme qui serait lié avec cette bibliothèque.
Le fichier qui peut etre supprimé, c'est /usr/lib/libc.so (qui a des chances de venir d'un paquet libc-dev, par exemple), qui est un lien symbolique vers le vrai fichier utilisé a l'exécution.
comment fait-on sous Linux pour fondre deux fichiers objets en un seul : toto1.o +toto2.o = toto.o ? C'est possible ? (Naturellement, j'ai parcouru longuement le manuel de gcc.)
ld -r Mais ce n'est pas une bonne idée, les archives (.a) sont plus adaptées.
candide
Marc Espie a écrit :
soit plus tard si tu charges explicitement ces objets un peu apres (a coup de dlopen/dlsym, c'est les "plugin" habituels).
Je savais même pas que c'était une possibilité offerte par les bibliothèques dynamiques (même si ça paraît logique après coup). Ça doit être rigolo de faire des trucs comme des plugins, ya un petit côté magique ...
Marc Espie a écrit :
soit plus tard si tu charges explicitement ces objets un peu apres (a coup
de dlopen/dlsym, c'est les "plugin" habituels).
Je savais même pas que c'était une possibilité offerte par les bibliothèques
dynamiques (même si ça paraît logique après coup). Ça doit être rigolo de faire
des trucs comme des plugins, ya un petit côté magique ...
soit plus tard si tu charges explicitement ces objets un peu apres (a coup de dlopen/dlsym, c'est les "plugin" habituels).
Je savais même pas que c'était une possibilité offerte par les bibliothèques dynamiques (même si ça paraît logique après coup). Ça doit être rigolo de faire des trucs comme des plugins, ya un petit côté magique ...
candide
Marc a écrit :
Le fichier qui peut etre supprimé, c'est /usr/lib/libc.so (qui a des chances de venir d'un paquet libc-dev, par exemple), qui est un lien symbolique vers le vrai fichier utilisé a l'exécution.
Merci mais j'ai pas osé et en plus je connais pas assez le maniement des bibliothèques dynamiques pour savoir comment refaire marcher mon exécutable.
Par contre, juste à côté de /usr/lib/libc.so j'ai vu qu'il y avait libc.a en en faisant
$ nm libc.a
je crois que j'ai toute la bibliothèque standard (et d'autres choses en plus je suppose) dans un gros fichier de 1,4 Mo
Si je compile en faisant gcc -static j'obtiens d'ailleurs un big exécutable qui passe de 6.5 Kio à 544 Kio !!
ld -r
Ah oui ça marche, j'aurais jamais pensé que ld faisait ça, merci.
Mais ce n'est pas une bonne idée, les archives (.a) sont plus adaptées.
D'accord, je vous fais confiance ;)
Marc a écrit :
Le fichier qui peut etre supprimé, c'est /usr/lib/libc.so (qui a des
chances de venir d'un paquet libc-dev, par exemple), qui est un lien
symbolique vers le vrai fichier utilisé a l'exécution.
Merci mais j'ai pas osé et en plus je connais pas assez le maniement des
bibliothèques dynamiques pour savoir comment refaire marcher mon exécutable.
Le fichier qui peut etre supprimé, c'est /usr/lib/libc.so (qui a des chances de venir d'un paquet libc-dev, par exemple), qui est un lien symbolique vers le vrai fichier utilisé a l'exécution.
Merci mais j'ai pas osé et en plus je connais pas assez le maniement des bibliothèques dynamiques pour savoir comment refaire marcher mon exécutable.
Par contre, juste à côté de /usr/lib/libc.so j'ai vu qu'il y avait libc.a en en faisant
$ nm libc.a
je crois que j'ai toute la bibliothèque standard (et d'autres choses en plus je suppose) dans un gros fichier de 1,4 Mo
Si je compile en faisant gcc -static j'obtiens d'ailleurs un big exécutable qui passe de 6.5 Kio à 544 Kio !!
ld -r
Ah oui ça marche, j'aurais jamais pensé que ld faisait ça, merci.
Mais ce n'est pas une bonne idée, les archives (.a) sont plus adaptées.
D'accord, je vous fais confiance ;)
YBM
candide a écrit :
Marc a écrit :
Le fichier qui peut etre supprimé, c'est /usr/lib/libc.so (qui a des chances de venir d'un paquet libc-dev, par exemple), qui est un lien symbolique vers le vrai fichier utilisé a l'exécution.
Merci mais j'ai pas osé et en plus je connais pas assez le maniement des bibliothèques dynamiques pour savoir comment refaire marcher mon exécutable.
Un bon exercice en la matière est de se fabriquer un système de fichiers minimal dans lequel on peut faire tourner quelques exécutables (un shell par exemple) et de tester tout ça avec chroot :
mkdir -p miniroot/lib miniroot/bin
colle ton hello dans miniroot/bin
ajoute ensuite ce qu'il faut tant que "sudo chroot miniroot hello" ne marche pas (indice : il faut coller ld-linux.so dans lib, celui n'est pas évident à trouver tout de suite, cf. man ld.so)
Ensuite il n'y plus qu'à ajouter un /dev et quelques détails annexe pour pouvoir coller tout ça dans une image disque et fabriquer un système embarqué testable avec qemu.
candide a écrit :
Marc a écrit :
Le fichier qui peut etre supprimé, c'est /usr/lib/libc.so (qui a des
chances de venir d'un paquet libc-dev, par exemple), qui est un lien
symbolique vers le vrai fichier utilisé a l'exécution.
Merci mais j'ai pas osé et en plus je connais pas assez le maniement des
bibliothèques dynamiques pour savoir comment refaire marcher mon exécutable.
Un bon exercice en la matière est de se fabriquer un système de fichiers
minimal dans lequel on peut faire tourner quelques exécutables (un shell
par exemple) et de tester tout ça avec chroot :
mkdir -p miniroot/lib miniroot/bin
colle ton hello dans miniroot/bin
ajoute ensuite ce qu'il faut tant que "sudo chroot miniroot hello"
ne marche pas (indice : il faut coller ld-linux.so dans lib, celui
n'est pas évident à trouver tout de suite, cf. man ld.so)
Ensuite il n'y plus qu'à ajouter un /dev et quelques détails annexe
pour pouvoir coller tout ça dans une image disque et fabriquer un
système embarqué testable avec qemu.
Le fichier qui peut etre supprimé, c'est /usr/lib/libc.so (qui a des chances de venir d'un paquet libc-dev, par exemple), qui est un lien symbolique vers le vrai fichier utilisé a l'exécution.
Merci mais j'ai pas osé et en plus je connais pas assez le maniement des bibliothèques dynamiques pour savoir comment refaire marcher mon exécutable.
Un bon exercice en la matière est de se fabriquer un système de fichiers minimal dans lequel on peut faire tourner quelques exécutables (un shell par exemple) et de tester tout ça avec chroot :
mkdir -p miniroot/lib miniroot/bin
colle ton hello dans miniroot/bin
ajoute ensuite ce qu'il faut tant que "sudo chroot miniroot hello" ne marche pas (indice : il faut coller ld-linux.so dans lib, celui n'est pas évident à trouver tout de suite, cf. man ld.so)
Ensuite il n'y plus qu'à ajouter un /dev et quelques détails annexe pour pouvoir coller tout ça dans une image disque et fabriquer un système embarqué testable avec qemu.
PIGUET Bruno
Le Mon, 02 Feb 2009 15:37:21 +0100, batyann811 a écrit :
Chez moi c'est /lib/libc-2.3.5.so. Mais ne t'aventures pas à effacer ou déplacer ce fichier car tu risques d'avoir de gros problèmes. Du genre ne plus pouvoir lancer aucun programme qui serait lié avec cette bibliothèque.
Mais on peut s'en sortir : http://weblog.elzevir.fr/2009/01/ma-vie-sans-libc/
Bruno.
Le Mon, 02 Feb 2009 15:37:21 +0100, batyann811 a écrit :
Chez moi c'est /lib/libc-2.3.5.so. Mais ne t'aventures pas à effacer ou
déplacer ce fichier car tu risques d'avoir de gros problèmes. Du genre
ne plus pouvoir lancer aucun programme qui serait lié avec cette
bibliothèque.
Mais on peut s'en sortir :
http://weblog.elzevir.fr/2009/01/ma-vie-sans-libc/
Le Mon, 02 Feb 2009 15:37:21 +0100, batyann811 a écrit :
Chez moi c'est /lib/libc-2.3.5.so. Mais ne t'aventures pas à effacer ou déplacer ce fichier car tu risques d'avoir de gros problèmes. Du genre ne plus pouvoir lancer aucun programme qui serait lié avec cette bibliothèque.
Mais on peut s'en sortir : http://weblog.elzevir.fr/2009/01/ma-vie-sans-libc/
