Bonjour,
est il possible de connaître les versions des noyaux Linux qui sont compatibles avec la librairie glibc que l’on trouve sur un système Debian ?
En regardant les sources de glibc on trouve une option de compilation --enable-kernel=VERSION qui permet de spécifier quelle version minimale du noyau peut être utilisée.
Comment accéder à ce paramètre sur un système Debian puisque l’on a pas les sources ou les options de configuration des librairies.
Merci pour votre aide.
S,
[quote=“Abaz”]Bonjour,
est il possible de connaître les versions des noyaux Linux qui sont compatibles avec la librairie glibc que l’on trouve sur un système Debian ?[/quote]
Houla Aabaz, tu ne l’as peut-ètre pas fait exprès : c’est l’inverse, et c’est bien le “problème” de GNU. Linux est tellement d’avant garde que c’est à la bibliothèque de ce bien se tenir. Cependant, de mémoire, je répondrai que mis à part la libc5.4.44, qui fut la dernière libc supportée exclusivement pour ce sytème depuis longtemps, voire même très longtemps, la glibc est entièrement compatible Linux, donc pas de soucis avec ça.
[quote]En regardant les sources de glibc[/quote] : Passe par git sur le site sourceware.org, s’il te plaît, sinon, tu ne sais pas de quoi tu parles, je sais faut l’oueb, et c’est pas cool. N’oublies pas que des centaines de personnes travaillent en “direct” sur cette bibliothèque incontournable.
Ton noyau, la commande $ uname -r va te donner ce que tu veux, i.e., la réponse à ta question.
Cela suppose d’avoir les sources pour ça … et d’avoir déjà compilé un header.deb pour le noyau en question : autrement dit un noyau.
Es-tu bien sûr de ce que tu fais ?
Tu préfères pas compiler “The Gimp” ??? 
@+
Bonjour,
je pense que je n’ai pas été suffisamment précis dans ma question, je vais essayer de la reformuler en y ajoutant un peu plus d’informations sur le contexte afin d’être le plus clair possible.
Je travaille sur un serveur ayant un système d’exploitation Linux avec un noyau 2.6.26 (c’est en effet ce que me donne la commande “uname -r”). Je compile une application C / C++ qui utilise la bibliothèque standard C glibc via une édition statique des liens. Cette application est destinée à fonctionner sur un autre serveur ayant également un système d’exploitation Linux mais cette fois ci avec un noyau 2.6.16.
Lorsque l’application a été lancée sur le serveur cible, le message d’erreur suivant a été renvoyé :
Après quelques recherches il s’avère que cette erreur est en général associée a la librairie glibc. En effet, lors de la compilation de glibc il existe une option de configuration qui permet de préciser quelle est la version minimale du noyau Linux qui peut être utilisée avec la librairie. Cette option est la suivante :
--enable-kernel=VERSION (voir sourceware.org/git/?p=glibc.git; … 155d716f0e)
Ainsi lorsque l’on utilise cette librairie avec un noyau plus ancien que VERSION, on obtient l’erreur mentionnée plus haut.
Ma question est donc la suivante : le système d’exploitation que j’utilise sur mon serveur est une distribution Linux Debian, qui est fournie avec une version déja compilée de la librairie glibc, est il possible de savoir quel paramètre VERSION a été utilisé lors de la compilation de glibc par les personnes qui maintiennent la distribution ?
J’espère avoir été un peu plus clair.
Merci pour votre aide.
En générale lorsque je compile un paquet pour une machine soit je m’arrange ( lorsque c’est possible ) de le faire depuis la dite machine soit je monte une machine virtuel minimale ( clone de la dite machine ) afin de le faire ce qui en générale m’assure d’une parfaite compatibilité.
Ce que je t’ai exposé et aussi valide pour faire de la compilation pour d’autre architecture ( ce qui est plaisant avec Debian car un grand nombre d’architecture sont supportées ) 
[quote]Lorsque l’application a été lancée sur le serveur cible, le message d’erreur suivant a été renvoyé :
[/quote]
C’est parce que cela vient de --enable-kernel qui n’est pas le bon. Tu trouveras toute la documentation que tu souhaite avec le paquet glibc-doc, pour ce qui concerne les changelog. Debian semble compiler la glibc avec “current” pour l’option --enable-kernel, depuis le 11 décembre 1999, Changelog.10.gz.
Évidement, les deux bibliothèques sont différentes sur les deux systèmes, même si c’est la même option, vu que ce n’est pas le même noyau de départ.
J’imagines cependant qu’en recompilant le programme sur le serveur cible, même si l’édition de liens est statique, cela va lui permettre de marcher. Et, ça, c’est parfaitement possible, non ?
Tu veux vraiment pas recompiler “The Gimp”, juste pour se marrer, avec “dh_make” !!! Non ? Sans façon ?
@+
Nota : [quote]c’est en effet ce que me donne la commande “uname -r”[/quote]
Merci, je connais mon boulôt et je pense avoir répondu parfaitement gratuitement à ta question.
Bonjour,
je suis bien d’accord avec toi Clochette la solution idéale serait bien sur de compiler directement sur le système cible mais malheureusement je n’y ai pas accès. La seconde meilleure solution serait alors d’avoir un clone du système soit sur une autre machine soit sous forme de machine virtuelle, mais le système cible utilise un système d’exploitation destiné aux entreprises et je n’ai pour l’instant pas envie de payer la licence. Les autres solutions sont de cloner un système suffisamment proche (j’ai commencé à essayer de travailler avec qemu mais je galère un peu), de recompiler glibc avec la bonne option (mais je lis un peu partout sur les forums que c’est une galère sans nom) ou avec de la chance simplement compiler l’application avec édition des liens dynamique.
Cependant ce qui m’intéressait dans cette question c’était de savoir si l’on pouvait prévoir ce genre de problèmes. Si jamais je sais que ma librairie glibc a été compilé pour fonctionner avec certaines versions du noyau Linux alors je pourrais au moins savoir quand je rencontrerais un problème.
Je ne sais pas si c’est possible mais cela serait quand même intéressant. D’ailleurs la question peut sans doute se généraliser un peu : lorsque l’on a un binaire précompilé, est il possible de remonter aux options qui ont été utilisées pour le compiler à partir des sources ? Je suppose que si les développeurs ne l’ont pas prévu cela va être difficile.
@Sirilam : est ce que l’option “current” signifie que la librairie est compilé avec uniquement le support pour le noyau actuel et les noyaux supérieurs ? Pourrais tu me donner un lien pour consulter les changelogs de Debian ? Je vois que la compilation de Gimp a l’air de te tenir à coeur mais je préfère m’abstenir. Par contre je n’ai pas compris ta remarque finale, je n’ai jamais insinué que tu ne connaissais pas ton boulot, d’ailleurs je ne sais même pas quel est ton boulot. Bref, merci pour tes réponses.
Je ne connais pas la commande qui pourrait te dépanner mais si tu fais une recherche sur snapshot.debian.org, tu trouveras le moment où le 2.6.16 est apparu et tu pourras regarder pour la même date quelle était la version de glibc. ( ou bien faire l’inverse, en partant d’une glibc donnée, quel était le noyau contemporain )
Salut,
+1 pour snapshot…
J’ai finalement trouvé le 2.6.16…
snapshot.debian.org/package/linux-2.6.16/
Il doit y avoir des infos dans la doc
[quote=“Aabaz”]
@Sirilam : est ce que l’option “current” signifie que la librairie est compilé avec uniquement le support pour le noyau actuel et les noyaux supérieurs ? Pourrais tu me donner un lien pour consulter les changelogs de Debian ? Je vois que la compilation de Gimp a l’air de te tenir à coeur mais je préfère m’abstenir. Par contre je n’ai pas compris ta remarque finale, je n’ai jamais insinué que tu ne connaissais pas ton boulot, d’ailleurs je ne sais même pas quel est ton boulot. Bref, merci pour tes réponses.[/quote]
Salut,
C’est plutôt difficile de te répondre simplement : je vais quand même essayer. Re-lis ce que je t’ai dit : installer glibc-doc. Si tu ne sais pas les fichiers qu’il installe, tu consulte le fichier /var/lib/dpkg/info/glibc-doc.list, tu verras alors l’emplacement des Changelog.
Soit alors, $ cd /usr/share/doc/glibc-doc ; zgrep -i '\-\-kernel\-option' *.gz , qui précise que le 1999-11-12, qui doit être le 12 novembre 1999 et non le 11 décembre 1999, c’est l’option current qui est utilisé !!! Je me répête de mon précédent envoi.
Ensuite tu as la doc, qui affirme conserver la compatibilité ascendante, c’est dans la documentation du lien que tu as donné : tu fais très fort.
Pour ma remarque, je crois qu’il ne faut pas insister.
Pour ton pb : 2.6.16 => 2.6.26 : ok. 2.6.26 => 2.6.16 : ?. Cela dit un coup de sed avec qqch comme s/2.6.16/2.6.26/g donnera peut-ètre le fixe voulu. En tout cas, comme les deux chaînes ont la même longueur et qu’il n’y a pas, nativement, de controle d’intégrité à l’intérieur de la bibliothèque C, ça peut fonctionner, à tester.
Quand à ce que tu dis, sincère : pense Unix s’il te plaît !
La question c’est pas de savoir si c’est possible, la question c’est de savoir si cela a un intérêt !
@+
Bonjour,
tout d’abord je tenais à vous remercier de prendre un peu de votre temps pour m’aider, c’est très gentil de votre part.
Je ne suis pas un expert des systèmes UNIX, j’ai simplement un problème très concret que je dois résoudre alors je vous prie de bien vouloir m’excuser si parfois je ne saisis pas du premier coup. Ceci dit si la question n’a pas d’intérêt on peut aussi arrêter la discussion ici. En attendant je vais essayer de faire le tour des solutions qui ont été proposées et que j’ai essayées :
*) J’ai installé le paquet glibc-doc comme me l’a conseillé Sirilam et effectivement on a bien accès aux fichiers “ChangeLog” mais en effectuant la même recherche je tombe sur :
[code]1999-11-12 Ulrich Drepper drepper@cygnus.com
*) Je ne vois pas de mention à une compatibilité ascendante générale dans la documentation, même s’il existe effectivement certaines fonctions qui sont conservées pour cela. D’après ce que j’ai compris l’option “–enable-kernel” vise justement à limiter l’ajout de morceaux de code qui sont destinés à maintenir une compatibilité ascendante.
*) Je n’ai pas compris comment utiliser sed pour faire la modification, à quel(s) fichier(s) faut il appliquer cette commande.
*) Merci à eol et lol pour le conseil sur le site patch-tracker.debian.org/patch/d … /2.11.2-10). On peut y trouver les options qui ont été utilisées lors de la compilation des sources (enfin je crois), j’ai délibérément sauté certains passage pour que cela soit plus lisible :
[code]— eglibc-2.11.2.orig/debian/sysdeps/linux.mk
+++ eglibc-2.11.2/debian/sysdeps/linux.mk
@@ -0,0 +1,51 @@
[…]
+MIN_KERNEL_SUPPORTED := 2.6.18
[…]
+# Minimum Kernel supported
+with_headers = --with-headers=$(shell pwd)/debian/include --enable-kernel=$(call xx,MIN_KERNEL_SUPPORTED)
[…]
+CURRENT_KERNEL_VERSION=$(shell uname -r)
+define kernel_check
+(minimum=$$((echo $(1) | sed 's/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*/\1 \* 65536 + \2 \* 256 + \3/'));
+current=$$((echo $(CURRENT_KERNEL_VERSION) | sed 's/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*/\1 \* 65536 + \2 \* 256 + \3/'));
+if [ $$current -lt $$minimum ]; then \
Ce qui me permet d’expliquer pourquoi j’ai rencontré cette erreur. Du coup je pourrais également prévoir à l’avance en fonction de l’évolution des deux machines si une application compilée sur l’une fonctionnera sur l’autre.
Merci à tous pour votre aide très précieuse.
PS : une chose que j’ai oublié, si on exécute /lib/libc.so.6 on obtient quelques informations sur le système qui a servi à compiler la librairie, ça n’a pas résolu mon problème mais j’ai pensé le mettre ici si ça peut aider quelqu’un qui tombe sur ce sujet.
GNU C Library (Debian EGLIBC 2.11.2-10) stable release version 2.11.2, by Roland McGrath et al.
[...]
Compiled by GNU CC version 4.4.5.
Compiled on a Linux 2.6.32 system on 2011-01-23.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
[...]