Comment, en général, le code binaire de la bibliothèque standard apparait-il
dans le système de fichier ?
Comment, en général, le code binaire de la bibliothèque standard apparait-il
dans le système de fichier ?
Comment, en général, le code binaire de la bibliothèque standard apparait-il
dans le système de fichier ?
telles que
fonctions mathématiques qui sont dans le fichier libm.so (c'est pour ça qu'il faut
lier avec l'argument -lm, regarde le manuel de
). Ces fichiers sont en fait les bibliothèques partagées.
telles que
fonctions mathématiques qui sont dans le fichier libm.so (c'est pour ça qu'il faut
lier avec l'argument -lm, regarde le manuel de
). Ces fichiers sont en fait les bibliothèques partagées.
telles que
fonctions mathématiques qui sont dans le fichier libm.so (c'est pour ça qu'il faut
lier avec l'argument -lm, regarde le manuel de
). Ces fichiers sont en fait les bibliothèques partagées.
candide a écrit :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 fichier :D Les fonctions de la bibliothèque
standard sont pour la plupart dans une bibliothèque nommée libc.so. La
plupart car il y a des exceptions, telles que les fonctions
mathématiques qui sont dans le fichier libm.so (c'est pour ça qu'il faut
lier avec l'argument -lm, regarde le manuel de abs). Ces fichiers sont
en fait les bibliothèques partagées. Lorsqu'un programme est exécuté,
les bibliothèques dont il a besoin sont chargées en mémoire. Il va s'en
dire que, si la bibliothèque est déjà chargée, l'OS ne recharge pas le
fichier.
Il y a aussi la forme statique, qui sont les fichiers que tu as
repéré suffixé par .a. Lorsque tu compiles en statique (flag -static de
ld), les fichiers objets (.o) contenus dans le fichier archive (.a) sont
inclus dans l'exécutable final. L'intérêt est que tu ne dépend pas des
bibliothèques installées sur le système. L'inconvénient, c'est le poids
du bestiaux, et l'emprunte mémoire.
Les fichiers .a sont des fichiers archive créés avec la commande ar,
contenant des fichiers objet (.o).
On créé une bibliothèque partagée avec la commande suivante par
exemple : cc -shared -Wl,-soname,libtoto.so -o libtoto.so toto.o
Sous Linux, les bibliothèques sont généralement rangées dans /lib/ et
/usr/lib/. Je te laisse chercher les archives ;) À noter que les
primitives système sont des symboles du noyau.
candide a écrit :
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 fichier :D Les fonctions de la bibliothèque
standard sont pour la plupart dans une bibliothèque nommée libc.so. La
plupart car il y a des exceptions, telles que les fonctions
mathématiques qui sont dans le fichier libm.so (c'est pour ça qu'il faut
lier avec l'argument -lm, regarde le manuel de abs). Ces fichiers sont
en fait les bibliothèques partagées. Lorsqu'un programme est exécuté,
les bibliothèques dont il a besoin sont chargées en mémoire. Il va s'en
dire que, si la bibliothèque est déjà chargée, l'OS ne recharge pas le
fichier.
Il y a aussi la forme statique, qui sont les fichiers que tu as
repéré suffixé par .a. Lorsque tu compiles en statique (flag -static de
ld), les fichiers objets (.o) contenus dans le fichier archive (.a) sont
inclus dans l'exécutable final. L'intérêt est que tu ne dépend pas des
bibliothèques installées sur le système. L'inconvénient, c'est le poids
du bestiaux, et l'emprunte mémoire.
Les fichiers .a sont des fichiers archive créés avec la commande ar,
contenant des fichiers objet (.o).
On créé une bibliothèque partagée avec la commande suivante par
exemple : cc -shared -Wl,-soname,libtoto.so -o libtoto.so toto.o
Sous Linux, les bibliothèques sont généralement rangées dans /lib/ et
/usr/lib/. Je te laisse chercher les archives ;) À noter que les
primitives système sont des symboles du noyau.
candide a écrit :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 fichier :D Les fonctions de la bibliothèque
standard sont pour la plupart dans une bibliothèque nommée libc.so. La
plupart car il y a des exceptions, telles que les fonctions
mathématiques qui sont dans le fichier libm.so (c'est pour ça qu'il faut
lier avec l'argument -lm, regarde le manuel de abs). Ces fichiers sont
en fait les bibliothèques partagées. Lorsqu'un programme est exécuté,
les bibliothèques dont il a besoin sont chargées en mémoire. Il va s'en
dire que, si la bibliothèque est déjà chargée, l'OS ne recharge pas le
fichier.
Il y a aussi la forme statique, qui sont les fichiers que tu as
repéré suffixé par .a. Lorsque tu compiles en statique (flag -static de
ld), les fichiers objets (.o) contenus dans le fichier archive (.a) sont
inclus dans l'exécutable final. L'intérêt est que tu ne dépend pas des
bibliothèques installées sur le système. L'inconvénient, c'est le poids
du bestiaux, et l'emprunte mémoire.
Les fichiers .a sont des fichiers archive créés avec la commande ar,
contenant des fichiers objet (.o).
On créé une bibliothèque partagée avec la commande suivante par
exemple : cc -shared -Wl,-soname,libtoto.so -o libtoto.so toto.o
Sous Linux, les bibliothèques sont généralement rangées dans /lib/ et
/usr/lib/. Je te laisse chercher les archives ;) À noter que les
primitives système sont des symboles du noyau.
Bonjour,
Comment, en général, le code binaire de la bibliothèque standard ap parait-il
dans le système de fichier ? sous la forme d'un seul (et assez gros ?) fichier
ou en plusieurs fichiers,
(<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-ell e 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 ?
Merci
Bonjour,
Comment, en général, le code binaire de la bibliothèque standard ap parait-il
dans le système de fichier ? sous la forme d'un seul (et assez gros ?) fichier
ou en plusieurs fichiers,
(<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-ell e 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 ?
Merci
Bonjour,
Comment, en général, le code binaire de la bibliothèque standard ap parait-il
dans le système de fichier ? sous la forme d'un seul (et assez gros ?) fichier
ou en plusieurs fichiers,
(<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-ell e 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 ?
Merci
Bonjour,
Comment, en général, le code binaire de la bibliothèque standard ap parait-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-ell e 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 ?
Bonjour,
Comment, en général, le code binaire de la bibliothèque standard ap parait-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-ell e 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 ?
Bonjour,
Comment, en général, le code binaire de la bibliothèque standard ap parait-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-ell e 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 ?
Ces .lib peuvent contenir soit tout le code (bibliothèque statiques,
Ces .lib peuvent contenir soit tout le code (bibliothèque statiques,
Ces .lib peuvent contenir soit tout le code (bibliothèque statiques,
Comment, en général, le code binaire de la bibliothèque standard apparait-il
dans le système de fichier ?
Comment, en général, le code binaire de la bibliothèque standard apparait-il
dans le système de fichier ?
Comment, en général, le code binaire de la bibliothèque standard apparait-il
dans le système de fichier ?
candide a écrit :Comment, en général, le code binaire de la bibliothèque standard apparait-il
dans le système de fichier ?
J'ai posé cette question parce je souhaitais mener une petite expérience
didactique.
Je me rappelle que lors ma découverte du C il y a un peu plus de trois ans,
j'avais été très intrigué par les explications que j'avais lues dans mon livre
de C sur le processus de compilation et en particulier par le rôle du code
objet, des fichiers .a, des fichiers d'en-tête (que je considérais comme
binaires) et de l'édition de liens. D'ailleurs, j'ai mis fort longtemps à
comprendre que les messages que m'envoyait mon compilateur n'étaient pas tous de
même nature (erreur de compilation vs erreur de liaison).
Voilà pourquoi j'avais envie de faire l'expérience suivante :
1°) je crée un fichier source toto.c contenant un printf("Salut !n");
2°) je supprime (ou je déplace plutôt) le fichier de bibliothèque (libmachin.a
ou libmachin.so) contenant le code de printf()
3°) je tente de "compiler" toto.c : échec avéré par un message (pas d'exécutable).
4°) je place le fichier de bibliothèque libmachin.* dans le répertoire de toto.c
5°) je compile avec la commande adéquate : l'exécutable est produit.
Avec le recul, je me dis qu'on m'aurait présenté les choses ainsi, ça m'aurait
paru beaucoup plus clair et j'aurais compris beaucoup plus vite.
Maintenant, je me rends compte que dans mes implémentations, il y a une
multitude de fichiers .a (Mingw) ou .so gcc sous Linux) et que je ne sais même
pas lequel supprimer. Donc mon expérience va probablement tourner court surtout
que j'ai pas envie d'y passer des heures et des heures.
Si je lance en console:
$ nm a.out
je n'obtiens même pas mention du printf que j'avais dans toto.c, j'ai le symbole :
08049574 d p.5841
U puts@@GLIBC_2.0
donc je ne sais pas si je dois déduire que le fichier à déplacer est GLIBC_2.0.so .
Bref, tout ça pour dire aussi que le traitement livresque des langages de
programmation ne donne pas son côté tangible au langage.
candide a écrit :
Comment, en général, le code binaire de la bibliothèque standard apparait-il
dans le système de fichier ?
J'ai posé cette question parce je souhaitais mener une petite expérience
didactique.
Je me rappelle que lors ma découverte du C il y a un peu plus de trois ans,
j'avais été très intrigué par les explications que j'avais lues dans mon livre
de C sur le processus de compilation et en particulier par le rôle du code
objet, des fichiers .a, des fichiers d'en-tête (que je considérais comme
binaires) et de l'édition de liens. D'ailleurs, j'ai mis fort longtemps à
comprendre que les messages que m'envoyait mon compilateur n'étaient pas tous de
même nature (erreur de compilation vs erreur de liaison).
Voilà pourquoi j'avais envie de faire l'expérience suivante :
1°) je crée un fichier source toto.c contenant un printf("Salut !n");
2°) je supprime (ou je déplace plutôt) le fichier de bibliothèque (libmachin.a
ou libmachin.so) contenant le code de printf()
3°) je tente de "compiler" toto.c : échec avéré par un message (pas d'exécutable).
4°) je place le fichier de bibliothèque libmachin.* dans le répertoire de toto.c
5°) je compile avec la commande adéquate : l'exécutable est produit.
Avec le recul, je me dis qu'on m'aurait présenté les choses ainsi, ça m'aurait
paru beaucoup plus clair et j'aurais compris beaucoup plus vite.
Maintenant, je me rends compte que dans mes implémentations, il y a une
multitude de fichiers .a (Mingw) ou .so gcc sous Linux) et que je ne sais même
pas lequel supprimer. Donc mon expérience va probablement tourner court surtout
que j'ai pas envie d'y passer des heures et des heures.
Si je lance en console:
$ nm a.out
je n'obtiens même pas mention du printf que j'avais dans toto.c, j'ai le symbole :
08049574 d p.5841
U puts@@GLIBC_2.0
donc je ne sais pas si je dois déduire que le fichier à déplacer est GLIBC_2.0.so .
Bref, tout ça pour dire aussi que le traitement livresque des langages de
programmation ne donne pas son côté tangible au langage.
candide a écrit :Comment, en général, le code binaire de la bibliothèque standard apparait-il
dans le système de fichier ?
J'ai posé cette question parce je souhaitais mener une petite expérience
didactique.
Je me rappelle que lors ma découverte du C il y a un peu plus de trois ans,
j'avais été très intrigué par les explications que j'avais lues dans mon livre
de C sur le processus de compilation et en particulier par le rôle du code
objet, des fichiers .a, des fichiers d'en-tête (que je considérais comme
binaires) et de l'édition de liens. D'ailleurs, j'ai mis fort longtemps à
comprendre que les messages que m'envoyait mon compilateur n'étaient pas tous de
même nature (erreur de compilation vs erreur de liaison).
Voilà pourquoi j'avais envie de faire l'expérience suivante :
1°) je crée un fichier source toto.c contenant un printf("Salut !n");
2°) je supprime (ou je déplace plutôt) le fichier de bibliothèque (libmachin.a
ou libmachin.so) contenant le code de printf()
3°) je tente de "compiler" toto.c : échec avéré par un message (pas d'exécutable).
4°) je place le fichier de bibliothèque libmachin.* dans le répertoire de toto.c
5°) je compile avec la commande adéquate : l'exécutable est produit.
Avec le recul, je me dis qu'on m'aurait présenté les choses ainsi, ça m'aurait
paru beaucoup plus clair et j'aurais compris beaucoup plus vite.
Maintenant, je me rends compte que dans mes implémentations, il y a une
multitude de fichiers .a (Mingw) ou .so gcc sous Linux) et que je ne sais même
pas lequel supprimer. Donc mon expérience va probablement tourner court surtout
que j'ai pas envie d'y passer des heures et des heures.
Si je lance en console:
$ nm a.out
je n'obtiens même pas mention du printf que j'avais dans toto.c, j'ai le symbole :
08049574 d p.5841
U puts@@GLIBC_2.0
donc je ne sais pas si je dois déduire que le fichier à déplacer est GLIBC_2.0.so .
Bref, tout ça pour dire aussi que le traitement livresque des langages de
programmation ne donne pas son côté tangible au langage.
donc je ne sais pas si je dois déduire que le fichier à déplacer est GLIBC_2.0.so .
Pendant que j'y suis, j'en profite pour poser la question technique suivante :
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.)
donc je ne sais pas si je dois déduire que le fichier à déplacer est GLIBC_2.0.so .
Pendant que j'y suis, j'en profite pour poser la question technique suivante :
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.)
donc je ne sais pas si je dois déduire que le fichier à déplacer est GLIBC_2.0.so .
Pendant que j'y suis, j'en profite pour poser la question technique suivante :
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.)
3°) je tente de "compiler" toto.c : échec avéré par un message (pas d'exécutable).
Sauf que justement, si tu ne faisais que la phase de *compilation*
(option -c de gcc), ça devrait compiler sans aucun problème. C'est
*l'édition de lien* qui devrait planter.
Maintenant, je me rends compte que dans mes implémentations, il y a une
multitude de fichiers .a (Mingw) ou .so gcc sous Linux) et que je ne sais même
pas lequel supprimer. Donc mon expérience va probablement tourner court surtout
que j'ai pas envie d'y passer des heures et des heures.
Je comprends. D'ailleurs, je pense que le but c'est justement que ce soit
le compilo qui s'en débrouille, et pas le programmeur (en général).
08049574 d p.5841
U puts@@GLIBC_2.0
J'en déduit que le compilo a été intelligent, et qu'il a remplacé l'appel
à printf (grosse fonction) à un appel équivalent ici à puts.
Moi non plus. Ceci dit, je me demande même si la machine redémarrerait
bien si on déplacait la libc sans prévenir le reste du système.
Bref, tout ça pour dire aussi que le traitement livresque des langages de
programmation ne donne pas son côté tangible au langage.
Un langage est une chose, son implantation en est une autre.
Après, il est vrai qu'en 2008, il ne reste plus que deux familles d'OS,
les Win* et les Unix-like, et qu'on pourrait se contenter de décrire le
fonctionnement "habituel" sur ces deux familles d'OS là.
3°) je tente de "compiler" toto.c : échec avéré par un message (pas d'exécutable).
Sauf que justement, si tu ne faisais que la phase de *compilation*
(option -c de gcc), ça devrait compiler sans aucun problème. C'est
*l'édition de lien* qui devrait planter.
Maintenant, je me rends compte que dans mes implémentations, il y a une
multitude de fichiers .a (Mingw) ou .so gcc sous Linux) et que je ne sais même
pas lequel supprimer. Donc mon expérience va probablement tourner court surtout
que j'ai pas envie d'y passer des heures et des heures.
Je comprends. D'ailleurs, je pense que le but c'est justement que ce soit
le compilo qui s'en débrouille, et pas le programmeur (en général).
08049574 d p.5841
U puts@@GLIBC_2.0
J'en déduit que le compilo a été intelligent, et qu'il a remplacé l'appel
à printf (grosse fonction) à un appel équivalent ici à puts.
Moi non plus. Ceci dit, je me demande même si la machine redémarrerait
bien si on déplacait la libc sans prévenir le reste du système.
Bref, tout ça pour dire aussi que le traitement livresque des langages de
programmation ne donne pas son côté tangible au langage.
Un langage est une chose, son implantation en est une autre.
Après, il est vrai qu'en 2008, il ne reste plus que deux familles d'OS,
les Win* et les Unix-like, et qu'on pourrait se contenter de décrire le
fonctionnement "habituel" sur ces deux familles d'OS là.
3°) je tente de "compiler" toto.c : échec avéré par un message (pas d'exécutable).
Sauf que justement, si tu ne faisais que la phase de *compilation*
(option -c de gcc), ça devrait compiler sans aucun problème. C'est
*l'édition de lien* qui devrait planter.
Maintenant, je me rends compte que dans mes implémentations, il y a une
multitude de fichiers .a (Mingw) ou .so gcc sous Linux) et que je ne sais même
pas lequel supprimer. Donc mon expérience va probablement tourner court surtout
que j'ai pas envie d'y passer des heures et des heures.
Je comprends. D'ailleurs, je pense que le but c'est justement que ce soit
le compilo qui s'en débrouille, et pas le programmeur (en général).
08049574 d p.5841
U puts@@GLIBC_2.0
J'en déduit que le compilo a été intelligent, et qu'il a remplacé l'appel
à printf (grosse fonction) à un appel équivalent ici à puts.
Moi non plus. Ceci dit, je me demande même si la machine redémarrerait
bien si on déplacait la libc sans prévenir le reste du système.
Bref, tout ça pour dire aussi que le traitement livresque des langages de
programmation ne donne pas son côté tangible au langage.
Un langage est une chose, son implantation en est une autre.
Après, il est vrai qu'en 2008, il ne reste plus que deux familles d'OS,
les Win* et les Unix-like, et qu'on pourrait se contenter de décrire le
fonctionnement "habituel" sur ces deux familles d'OS là.