Discussion :

[Gnux]

Bonjour Gnux,

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

Si, simplement ce forum tend à devenir comme la glibc et comme cette dernière il n'y a pas de moyen de l'appréhender vraiment facilement et clairement (Gnus nostalgie...)

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.

Pour faire de l'importation privilégie le statique. Ensuite si ton binaire ne marche pas tu peux toujours rusé (par exemple en utilisant brandelf sous les *BSD). Mais il est aussi sur que monter toute une distribution à partir de packages pré-compiles sur un autre ordi...Si tu veux de la légèreté et de l'efficacité je te conseille (sans rire) Minix. Perso je vais tester ce système via qemu mais ça m'a vraiment l'air intéressant et très utilisable. De surcroit vue le caractère de Tanenbaum, le featurisme n'y a pas cours...

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.

Vue comme ça ça ne m'étonne plus...Le souci c'est que qud tu importes des libs compilés dynamiquement tu n'emportes pas avec les dépendances .so...Essaie en statique pour tes petites applis mais pour toute une distro...

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).

C'est le genre de milieu dans lequel on dit que la seule bonne doc c'est le code. L'ennui (principal) c'est que qud tu commences à lire la doc puis le code tout se détricote et tu te retrouves obligé de lire tels ou tels fichiers pour comprendre tel autre mais tu as oublié celui là donc tu ne comprends pas ce que c'est que cette variable etc...Ca devient vite illisible d'autant que sur des projets de cette taille et complexité il est très difficile de garder une écriture (coding style) homogène...La glibc est un grand foutoir dont il est très difficile d'arrêter une segmentation (contrairement au kernel ou tu peux prendre les canoniques gestion de la mémoire/ systèmes de fichiers/réseau etc....)

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).

Récemment plusieurs appels systèmes ont été ajoutés et encore une fois ce fut un joli pugilat sur la lkml...Franchement Ullrich Drepper a bcp de courage car je crois qu'aujourd'hui vue son état (à la glibc) il faudrait repartir de 0 tant au niveau du code que de la gestion du projet...

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.

Voilà pourquoi je suis passé à freebsd puis au bsd en général. Je trouve que les gens sur les mailing (pe zul pourra confirmer ou infirmer) font moins le forcing pour avoir leur feature d'inclus dans le noyau. Aujourd'hui sur la lkml on voit des tonnes de patch qui ne font qu'une chose:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 if (blabla){
     do_that_in_a_new_fancy_way;
     }
else{
     use_the_old_boring_way;
     }

Alors évidemment au bout d'un certain tps...

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!

Ca je ne savais pas, je pensais qu'il y avait des boulversements d'api mais je pensais qu'ils essayaient au moins de préserver une compat backward

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...

Non la doc est bien, ce qui ne va pas, c'est le modèle "bazar" à partir du moment ou les gens se soucient plus de leur ego (avoir son nom sur le fichier credits du noyau) que de l'intéret de linux (regarde les débats sur ext4 qui commencent...)

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...

Eh bien change de système
Il n'y a pas que Windows. Il y a les *BSD et aussi d'autres projets (regarde minix). Cela te permettra (comme à moi d'ailleurs!) de prendre du recul et de voir vraiment ce qui ne va pas

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...

Oh non ça m'étonnerait que ça ne soit pas possible. Netbsd ça fonctionnerait même sur un stylo plume
Moi j'ai un vieux 486 sous open qui ronronne paisible. En fait il ronronne depuis si longtps que j'ai oublié sa config
Si tu as vraiment un petit matos regarde netbsd , c'est de l'os de geek mais ça tourne