[GLIBC & gcc] comment forcé la compatibilité avec GLIBC_

Bonsoir,

quand on compile avec GCC, si on utilise une liaison dynamique, le système de compilation/liaison laisse apparement une marque dans le binaire produit, et cette marque est testé par le chargeur au lancement de l'application.

Ainsi, j'ai compilé une application sur un système basé sur GLIBC_2_3, et je ne peux pas la faire fonctionner sur un système basé sur GLIBC_2_2 (alors que toutes les librairies sont pourtant bien présente).

J'ai envie de faire une remarque tout d'abord : on code une application en utilisant une interface (les entête), et des librairie sont cencées implémenter cette interface. Seulement ces librairie se permettent apparement d'imposer une contrainte qui n'existe pas dans l'interface (c'est un peu n'importe quoi)... soit GLIB_C_2_2 et GLIB_C_2_3 implémente une même interface, soit il ne le font pas.

Je me pose donc deux questions : GLIB_C_2_2 et GLIB_C_2_3 implémente-ils la même interface ? (normalement oui, mais le comportement qui va par la suite tendrait à montrer le contraire).

Existe-il un moyen d'imposer en compilant dans un environnement GLIB_C_2_3 que les binaires produits fonctionnent dans un environement GLIB_C_2_2 (normalement qui peu le plus peu le moins, mais vu qu'avec le C on est dans la quatrième dimmension, je n'en suit pas sure).

Quelqu'un(e) a une explication rationel à ce comportement irrationel ?




(quand sous windows je compile sur un système qui a une version corrigé de, disont, la dll-xyz, si l'interface est la même, ça fonctionne sur toute les plate forme windows pour lesquelles la dll-xyz fourni la même interface... linux n'est pas compatible avec linux ?)

Je ne pense pas que ce soit n'importe quoi, j'ai déjà eu le problème en passant d'une version à une autre, juste parce que j'avais des fonctions qui été présente dans mon programme mais qu'une version antérieure de GLib ne fournissait pas ces fonctions .... Surtout qu'en générale on progresse dans les version, mais on ne regresse pas, programmer avec une 1.0 et utiliser une version 0.1 beta (pour exemple) serais tout à fait nul non ?

Je ne conteste pas ça, mais quand on utilise des entête qui font référence à la version X d'une interface, et que le compilateur vous produit un binaire qui est contraint à être lié à la version X+n, il faut reconnaître qu'il y a un problème quelque part....

de quelle sémantique parle tu ? le C est très clair sur ce qu'il définit et surtout ce qu'il définit pas.

Pour répondre à ta question, je ne me rappelle pas avoir trovué un moyen de le faire. Je chercherai toutefois plutot du coté de ld que de gcc.

La glibc comme beaucoup de produits gnu explosent "en features" et surtout "en bloat", je suis assez d'accord avec toi. La rancon de la célébrité ?

Bonjour Zul, ça fait plaisir de te lire : mon BSD'iste préféré :)

Pour ce qui est de la sémantique du C, je suis au regret de te dire qu'en C.... il n'y a aucune sémantique.... la seul sémantique qu'il y ait est dans la tête du programmeur/de la programeuse, mais le langage n'en exprime rien, parce qu'il n'en a pas la capacité.

Sans aller chercher jusque Eiffel ou Ada, essaie déjà simplement le Pascal.... tu verra toute la différence. Je ne maitrise pas du tout Ada (pas encore), mais j'ai bien pratiqué Pascal, et il est pour l'instant la seule expérience (personelle) qui m'ait laissé un bon souvenir.

Mais ne le prend pas mal surtout, parce que j'apprécie bien ton naturel et ta franchise.

A vrai dire, le featurisme est toujours ce qui menace le logiciel : il n'y a qu'a voir ce qui est arrivé au C++ (qui était de toutes façons bien mal parti).... voir ce qu'est devenu le C avec GCC (qu'on ne peut pas compiler avec un simple compilateur conforme), et c'est aussi ce qui fait que l'on confond les caractéristiques sémantiques d'un langage et les librairies qui sont fournies avec. On juge plus un langage par ses librairies que par ce qu'il apporte conceptuellement (exemple flagrant avec PHP).

.... des effets du featurisme encore.

Une question que je me pose sur tous ses système atteint d'inflationisme aigu (y compris le kernel Linux, surtout depuis le 2.6) : y at-il quelqu'un(e) au commande ? Est-il maintenant toujours permis à tout le monde d'en percevoir clairement l'architecture globale, sachant que cette architecture globale n'est documenté null part ? Quand on voit que les documentation d'une application sont souvent écrite bien tardivement, et en plus par une personne tierce à l'auteut de l'application, qui a dut en deviner les rouages, on imagine alors les effet du featurisme sur la réelles maitrise de systèmes qui enfle et qui enfle sans cesse....

Qui représente la cohérence et la fonction fondamentale de GLIBC ?

Peut-être est-ce aussi une conscéquence de l'Open-Source aussi (du moins peut-être y contribut-il parce que tout le monde se lâche sans qu'il n'y ai de véritable chef d'orchestre)

Je ne sais pas, je part dans des suppositions....

Voilà que je part hors-sujet sur mon propre topic now ;)

Une piste pour laquelle j'aurais besoin d'appuis, vu que je ne maitrise pas gcc et ld. Le cas avance un peu, et tel qu'il se présente maintenant, il sera peut-être plus parlant à certain(e)s.

J'ai essayé en utilisant l'option « -nostdlib » (avec un seul tiret, et non pas deux), que j'ai trouvé dans une page man de ld, et qui semble également acceptée par gcc qui la retransmet correctement à ld. J'utilise l'option -L pour donner le chemin de la librairie vers laquelle la liaison dynamique doit se faire. Il s'agit de libc.so.5. Il faut juste renomer libc.so.5 en libc5.so, pour que le nom se termine par so, et que le lieur retrouve la librairie à partire de l'option -l (l minuscule, et non pas i masjuscule).

Par exemple je compile ainsi « gcc -nostdlib -L. -lc5 bonjour.c ».

Je teste avec « ldd ./.aout »

J'obtiens le resultat « libc.so.5 => not found ». C'est normal, car il n'y a pas de libc.so.5 dans les chemins du lieur dynamique.

J'importe a.out sur la plate forme basée sur libc.so.5 (sur laquelle il n'est pas possible d'installer gcc, malheureusement).

Je teste encore avec « ldd ./a.out »

J'obtiens « libc.so.5 => /lib/libc.so.5 ». OK.

Quand je lance le programme, il m'affiche bien « Bonjour! », mais il se termine par une faute d'accés mémoire (segmentation fault).

A noter que si au lieu de compiler/lier par gcc, je compile l'objet seulement, et que je lie ensuite avec ld, j'obtiens le message
« ld: warning: cannot find entry symbol _start; defaulting to 0000000008048234 ».

Le point d'entré semble être bien trouvé, puisque l'application s'execute bien (donc le point d'entré pris par défaut semble être le bon)... mais il y a un problème quand même à la terminaison du programme.

Aprés contrôle des symbole défini dans a.out et lib5.so, en employant la commande « readelf -s fichier », le symbole _start n'apparait ni dans a.out ni dans libc5.so. C'est étrange. Donc alors c'est ld qui semble chercher ce symbole de son propre chef ? Que fait ld au juste ? Il ne cherche pas « main » ?

Ca sent encore trop le bricolage, je n'aime pas ça.

Si quelqu'un(e) reconnait des éléments familiers à l'étape où j'en suis, je serai reconnaissant par la pensée de l'aide apportée.

Merci :P

(il rame le hibou, il rame dans le mazout, marée-noire en forêt, comme les pauvres mouettes qu'il est le pauvre hibou, ayez pitier)

Ca me rappelle quelquechose et quelquechose de pas agréable :). Personnellement, ca segfaultait avant le début du programme ( le entry point était décalé ). Le problème c'est que gcc et la libc sont très imbriqués ( voir par exemple le processus de compilation d'un cross compilateur ( ca serait aussi vrai pour un compilateur "normal" ). Je me demande donc si il est possible de faire ce que tu veux faire.

Lors de la création de l'executable ( etape de liaison ), on réunit lse différents éléments objet ( les .o ), les librairies statiques, on crée les sections pour les librairies dynamiques et puis y'a les magics objects crt0 et cie ( code pre-main qui va appeller libc_start__ et post_main qui va faire le ménage ). Ces crt0 dépendent de gcc et de la glibc . Je me demande donc si il ne te faut avoir un compilateur gcc + old glibc pour pouvoir récupérer les ctr0 ...( edit : il faut rajouter -nostartfile à ld pour avoir modifier les crtr0 qu'il utilise ). Ce n'est qu'une supposition toutefois.

fin post technique

Je te rassure, je ne fais pas que du C. Je fais du C pour tout ce qui est prog système et voila. J'aime bien faire du ruby voir de temps en temps du ocaml a coté :).

Ce que tu décris la est la théorie du bazar :). Qui peut aussi bien être un bienfait qu'un fleau. C'est pourquoi je préfére de loin le modèle BSD ou tu as toujours une poignée de personnse qui ont une vue globale du projet, et qui pousse le developpement dans une certaine voie. Au contraire de linux ou j'ai un peu l'impression que tout va un peu dans tous les sens, ce qui risque de poser un problème a plus ou moins long terme. Pour la glibc, je ne sais pas, mais quand je vois le code, je préfére me cacher et pas trop réfléchir .

Pour le C et GCC, je ne suis pas trop d'accord. gcc est très respectueux du standard. Il y'a toujours des gnueries mais personne ne t'oblige a les utiliser. evidemment gnu utilise ses gnuerise pour ses projets donc ca pose des problèmes ( enfin moi ca me pose des problèmes ). Mais je ne suis pas sur que ic++ ou autre se compile mieux avec un compilo purement standard. Le problème du C au final, ce sont la horde de mauvais développeurs, et la horde de gens qui utilisent des trucs gnuerie ou msrie ...

glibc a l'aire effectivement fortement intriquée dans le système : FAQ glibc topic 8 On est loin d'une simple bibliothèque C.

Les librairies ne sont pas indépendantes entre-elles: FAQ glibc topic 11 Segmentation inutile et non-pertinante.

La sémantiques des fonctions changent effectivement au gré des versions : FAQ glibc topic 11 Inutile d'espérer que la référence à une interface soit la preuve de quoique ce soit : portabilité formellement nul pour les applications qui se basent sur glibc.

Les correspondance pour libc sont établies ainsi (ceci est important pour comprendre).

Code:

---

1 2 3 4

libc-4 -> a.out libc libc-5 -> original ELF libc libc-6 -> GNU libc

---

Ceci explique pourquoi libc.so.6 est beaucoup plus lourde que libc.so.5
Et donc apparement encore, les versions de glibc sembleraient toujours correspondre à libc6. Pourtant j'avais cru lire quelque part que à partire de glibc2, on est avec libc6, et que avant glibc2, on est avec libc5...

il y a une relation entre ld-linux et glibc. Si on fait une liaison dynamique vers libc.so.5, alors le lieur dynamique doit être ld-linux.so.1. Si on fait une liaison dynamique vers libc.so.6 alors le lieur dynamique doit être ld-linux.so.2. Comme le lieur (ld) ne selectionne pas automatiquement le bon lieur dynamique (alors qu'il le pourrait, et le devrait), il faut lui indiquer explicitement. Par exemple : « --dynamic-linker=/lib/ld-linux.so.1 » si on veut lier dynamiquement avec libc5. Si vous passez le paramètre à gcc, plutôt que directement à ld, alors vous devez préfixé par « -Wl, » pour bien signifier à gcc que l'option doit être passé au lieur (par exemple « -Wl,--dynamic-linker=/lib/ld-linux.so.1 ».

libc4 correspondant aux executables au format a.out, et le format a.out n'ayant pas été conçus pour permettre la laison dynamique, la question de ld-linux.so ne se pose pas avec libc4 (en fait la liaison dynamique est possible avec le format a.out, mais c'est au prix de détours et de nombreuses complications).

Code:

---

1 2 3 4

libc5 -> ld-linux.so.1 libc6 -> ld-linux.so.2 (pour les implémentation gnu seulement de glibc, apparement)

---

Gcc n'est pas strictement associé à glibc, puisqu'il est possible de compilé avec gcc, en utiliant libc (et donc pas glibc).

Entre parenthèse, une chose qui me gêne avec glibc, c'est qu'elle regroupe trop de chose en une seule librairie, et qu'une segementation aurait certainement été préférable. Par exemple, beaucoup de fonctions systèmes aurait dut être placées dans une librairie à part (elle ne constitue pas la bibliothèque de base d'une application).

en fait, pour ne pas employer automatiquement les bibliothèques par défaut (celle de la configuration du système sur lequel on compile), il y a une autre option en plus de -nostdlib, il y a aussi -nodefaultlibs. Deux nom quasiment semblable (couche, et surcouche, et re-surcouche oblige). -nodefaultlibs ignore les bibliothèque par défaut, mais maintient la liaison vers les routines d'initialisation et de fin du programme (celle de crt). Et l'option -nostdlib, ignore toutes les librairies standards, y compris les procédures d'initialisation.

Je pensais que le problème venait de là, et qu'il suffirait de remplacer -nostdlib par -nodefaultlibs, puisque j'ai bien sure besoin de l'initialisation du programme que fait crt. Mais ça ne marche pas non-plus.

J'ai tout de même encore essayé avec -nostdlib, mais cette fois ci en ajoutant lgcc (pour ajouter les routines d'initialisation), mais là idem, rien de bon, et le lieur me renvoie des erreurs de symboles non trouvés.

Une autre remarque, il semble bien que gcc interprète lui-même les option du lieur avant de les passer au lieur, puisque par exemple si on invoque gcc avec -nostdlib, on peut voir (avec readelf) que les symboles produit par la compilation ne sont pas les mêmes avec et sans l'option.

Est-ce qu'il y a des gens ici qui maitrisent l'usage des options -nostdlib et/ou -nodefaultlibs ?

Oops, ailleurs je lis que ld-linux.so.1 doit être utilisé pour les applications à lier avec glibc2.1 et ld-linux.so.2 pour les applications à lier avec glibc2.2 et +.

Donc alors libc5 correspond à glibc2.1 ? (vu que ld-linux.so.1 est pour les applications à lier avec libc5)

C'est bien ça ?

P.S. Ceci n'est pas un blog, et vous êtes bien sur le forum developpez.net

Le B.A.ba de ce qu'il faut lier sous Linux :

(source : http://dev.gentoo.org/~vapier/crt.txt )

Citation:

---

Envoyé par crt.txt

Mini FAQ about the misc libc/gcc crt files.


Some definitions:
PIC - position independent code (-fPIC)
PIE - position independent executable (-fPIE -pie)
crt - C runtime



crt0.o
Older style of the initial runtime code ? No one generates this anymore.
crt1.o
Newer style of the initial runtime code. Contains the _start symbol which
sets up the env with argc/argv/libc _init/libc _fini before jumping to the
libc main. glibc calls this file 'start.S'.
crti.o
Defines the function prolog; _init in the .init section and _fini in the
.fini section. glibc calls this 'initfini.c'.
crtn.o
Defines the function epilog. glibc calls this 'initfini.c'.
Scrt1.o
Used in place of crt1.o when generating PIEs.
gcrt1.o
Used in place of crt1.o when generating code with profiling information.
Compile with -pg. Produces output suitable for the gprof util.
mcrt1.o
Like gcrt1.o, but is used with the prof utility. glibc installs this as
a dummy file as it's useless on linux systems.

crtbegin.o
Compiler constructor code ?
crtbeginS.o
Used in place of crtbegin.o when generating shared objects/PIEs.
crtbeginT.o
Used in place of crtbegin.o when generating static executables.
crtend.o
Compiler deconstructor code ?
crtendS.o
Used in place of crtendS.o when generating shared objects/PIEs.



General linking order:
crt1.o crti.o crtbegin.o [-L paths] [user objects] [gcc libs] [C libs] [gcc libs] crtend.o crtn.o

---

Est-ce que quelqu'un(e) a des infos sur les procédure libc_csu_fini, libc_csu_init et libc_start_main ?

Il n'y a rien sur le sujte avec google :(

Ces procédures sont référencées par crt*.o, mais je ne sais pas à quoi elles correspondent, ni dans quels fichiers objets elles se trouvent

Thanks for all

up!

Hi all,

Ce thread est toujours d'actualité...

Est-ce que quelqu'un(e) peut m'indiquer des sources d'informations sur les différentes version du processus d'initialisation d'une application avec glibc ?

Quand je fais des recherche sur google, par exemple pour libc_csu_init, je tombe soit sur mon propre post, soit sur un mail d'une mailing-list qui ne m'apprend absolument rien ?

D'ailleur je me demande : comment est dévellopé glibc ? Puisqu'apparement il n'existe aucune documentation détaillé sur glibc.... C'est du bricolage (interprétations de code et de pauvres commentaires, etc) ? Ca se passe comment ?

Ma remarque va être hors-sujet, mais peut-on parler d'open source, et de dévellopement open source, quand l'open source n'est même pas documenté ? ... peut-on parler de dévellopement dans ces cas là ?

Peut-être dans la doc officielle de la GLibC: http://www.gnu.org/software/libc/man...ode/index.html

Merci CSoldier, c'est gentil d'avoir répondu :)

J'avais déjà vu ce document, et d'autres similaires. Mais ça ne m'a pas apporté les informations que je recherche, parce que ça ne concerne que l'interface, et non pas le fonctionnement de la Glibc. Par exemple, les fonctions d'initialisation dont je parle plus haut, n'y sont pas documentées :(

Tant pis... je me demande si je ne vais pas abandonné ce projet finalement.

Quel était le but au final ?

Si tu veux avoir des réponses à ce genre de questions, je te conseille de poster une question sur la mailing list de developpement de la glibc. Ils devraient repondre gentimment ( peut-etre ).

Information utile :

Citation:

---

• La libc-6 est en réalité d'origine GNU, c'est la glibc-2 :-)
• La libc-5 et la glibc sont différentes :-)

---

Source : La Libc : GNU ou pas ?

Citation:

---

Envoyé par zul

Ce que tu décris la est la théorie du bazar :). Qui peut aussi bien être un bienfait qu'un fleau. C'est pourquoi je préfére de loin le modèle BSD ou tu as toujours une poignée de personnse qui ont une vue globale du projet, et qui pousse le developpement dans une certaine voie. Au contraire de linux ou j'ai un peu l'impression que tout va un peu dans tous les sens, ce qui risque de poser un problème a plus ou moins long terme. Pour la glibc, je ne sais pas, mais quand je vois le code, je préfére me cacher et pas trop réfléchir .

---

Un gros +1.
Ceci étant dit, l'interface je pense change d'une version à une autre de la glibc mais "ils" essaient de préserver une certaine compatibilité backward.
Donc moi pour faire joujou avec ce binaire un peu bizarre à l'entry point "décalé" j'utiliserais soit un parser binaire (pour l'utiliser et voir ce que ça donne mais aussi pour tacher de comprendre comment ça fonctionne!), regarde du coté de hachoir par exemple pour ça.Et je pense que je me ferais plaisir en testant elfsh.
En clair, je partirais de ce que j'ai (un binaire qui ne marche pas) plutot que de travailler sur des hypothèses du "pourquoi ça marche pas".

PS:pour ce qui est de la glibc, comme du noyau linux, je pense que c'est devenu un vrai maquis. Il y a énormément de bloat, c'est normal, tout le monde veut avoir son nom dans le fichier AUTHORS ou CREDITS :roll:

EDIT: si tu veux, tu peux attacher le code que tu as compilé + la facon dont tu l'as compilé. Je vais faire la même chose que toi sur une suse 10.1 avec une glibc rutilante. On verra si moi aussi j'ai ce problème...

Bonjour Gnux,

et merci pour ce message dans ce topic, je pensais que ça n'interessait plus personne...

Je ne sais pas si tu répondais à moi ou à Azul en parlant de faire un test de compilation.. mais bon, en ce qui me concerne, j'ai eu des problèmes d'ordre trés variés : en voulant importé des binaires venant d'ailleurs et qui référençait des librairie existante, mais pas de la bonne version (même un simple hello world compilé en liaison dynamique sur débian, ne fonctionnait pas sous un système de test, avec pourtant toute les librairies fondamentals...). En fait, le problème était que comme je n'ai pas de linux, et que je voulais recompilé des applications pour essayer de me faire une distribution légère, j'étais obligé de les compilé sur le serveur de mon site (je sais, c'est pas fait pour ça, mais on ne m'a pas remarqué apparement). Bon, même applications totalement basique ne fonctionnait pas, pour des différence de version de lib vraiment mineure.

Ensuite, j'avais voulu prendre des fichiers objet compilé avec gcc sous windows, pour les lier sur le serveur... et même là, ça ne marchait pas.. apprement dut à des problème de laison avec des routines d'initialisation. Alors j'ai voulu savoir d'où venait le problème, et comprendre comment fonctionnait l'initialisation des applications avec les glibc.

Là je me suis aperçus que tout est complétement segmenté, et qu'il y a des bribes répartis un peu partout, à tous les endroit. Ca m'a fait peur... je me suis dit « c'est quoi ce fouilli ». Ensuite, j'ai quand même voulu persevérer, et comprendre comment ça fonctionnait en détail, et être éclairé sur ces différents éléments disparate et éparpillés. Et là, je me suis aperçus, avoir chercher pourtant longtemps, que ça n'est même pas documenté, et que pour comprendre comment ça marche, il faut avoir fouiner dans les codes sources (problèmes récurrent, mais qui reste intolérable à mes yeux).

J'ai senti qu'il y avait un énorme problème du coté des glibc et des applications se chargeant de la liaison dynamique (le plus gros problème sous linux à mon avis, et de loin... dommage pour un aspect si fondamental). Donc j'ai voulu me renseigner sur glibc en générale. Et là, rien... Tout ce que j'ai trouvé, c'est que quelques autres personnes étaient également perturbées par cette obscurentisme, et que dans les mailing, elles n'ont jamais reçu de réponses (c'est pas encourageant).

Par exemple, étant que les glibc sont incompatible entre elles, j'ai voulu me renseigner sur ce qui les distingue. Même un document qui décrit les différences entre les différences version.. ça n'existe pas. Il parraitrait qu'il a exister à une époque un tel document sur le site de gnu, mais je ne l'ai pas trouvé. Je leur ai envoyé un mail pour être renseigné, mais mon mail est systèmatiquement rejeté.

Je ne sais plus comment faire pour faire les choses avec compréhensions, parce que j'ai toujours l'impression que sous linux on agit en aveugle et en bricolant.

Une chose que j'ai appris : il parrait que sous les linux moderne, il n'y a pas moins de trois version minimum de glibc, et que ces différentes versions sont totalement incompatible entre-elles!

Il y a beaucoup de problèmes avec linux, surtout en ce qui concerne sa documentation... mais le plus gros problème, la plus grosse faille, c'est vraiment la glibc et les chargeurs...

Bref, je suis complétement desespéré... et analysé les binaires, je faisait ça sous dos, quand je n'avais pas le net et aucun document... je m'étais interessé à linux au début, parce qu'on m'avait c'est ouvert et donc bien documenté... cruelle deception, alors j'avais abandonné pour revenir au grand méchant loup. Et là que je suis obligé de m'y remettre pour un problème d'Ada... je souffre...

pfffff.... je le disais à un moment dans ce post... malgré tout mes efforts pour clarifier les choses... je crois que je en vais pas tarder à abandonner.


P.S. J'aimerais beaucoup découvrire BSB, ça a l'air beaucoup plus fiable et cohérent... mais je ne peux pas :( ... avec mon poussif, c'est pas possible. Et puis sous BSD, je ne sais pas si je peux compiler de l'ada qui fonctionnerait sous débian...