vous avez fait vous avez de pbs en passant a la 3.80
 
heu et Glibc2.3 aussi pendant qu'on y est ?  
 

Sllllllllllllllllllyyyyyyyyyyyyyyyyyyyyy seconde partie de la question au rapport  

GLIBC 2.3 :
 
PC 1 :
 
avec gcc 3.2 ( patché glibc 2.3, make 3.80, binutils et libtools à jour ) :
 
compilation glibc 2.3 + linuxthreads 2.3 -> OK
 
compilation des applis après -> undefined reference to : __ctype_b
 
En fait dans libc6.so il est défini comme __ctype_b@GLIBC2.0
 
Si quelqu'un sait comment ça se fait et/ou se corrige ( pas trouvé sur le net )
 
Il y a un cas relativement similaire à ma situation quand même : http://ricardo.ecn.wfu.edu/glib-li [...] /0042.html ( D __ctype_b au lieu de d __ctype_b sur un nm qui fait tout merder visiblement )
 
 
PC 2 :  
 
avec gcc 3.2 et le reste issu de la Woody  
 
compilation glibc 2.3 + linuxthreads 2.3 -> error -> multiples definitions of __ctype_b@GLIBC2.0
 
problème également rencontré par une autre personne sur geowrawler : http://www.geocrawler.com/lists/3/GNU/360/0/9785555/
 
 
Voilà pour moi, j'en suis là, MySQL nous a informé qu'ils avaient commencé à mettre glibc 2.3 pour tester leur produit dessus et bosser avec cette version, mais ça a merdé aussi chez eux et donc ils ont remis la 2.2.5 rapidement pour taffer.
 
J'en sais pas plus, y'a quelqu'un qui l'a installé avec succès ? ( que tout compile derrière sans problème )

bon pour le moment 2/2 a ne pas arriver avec la 2.3
humpf de sreugneugnzeu

Bah déjà l'erreur pour le PC 2 je peux confirmer que c'est binutils qui n'est pas a jour mais forcement en mettant binutils a jour on tombe sur le cas du PC 1 ( au moins c logique de ce côté là )
 
le type __ctype_b était bien déclaré sur ce qu'il avait reussi à compiler sur le PC 2 mais le make torchait, maintenant avec un binutils à jour le make se termine sans erreur mais comme pour le PC 1 le __ctype_b n'est plus déclaré

je sais pas pq je reste perplexe  
 
tu as mis qq chose de special a la compile (j'entend argument au configure et make )?
 
note pour plus tard attendre que sly est testé les maj avant de les lancer chez moi

en mettant le lic.so.6 de la compile avortée du PC 2 avec le reste sur le PC 1 du make qui a terminé avec succès, bah ça marche sauf que... l'erreur de compile du PC 2 se répercute maintenant sur les autres applis après ( logique remarque )
 
Enfin bref, y'a un bug report déjà de lancé à ce sujet, wait & see...

elles apportent quoi ces nouvelles versions exactement ?

 
gestion plus rapide des threads, je voudrais bien pouvoir comparer en pratique... ( parce que ngpt normalement il est mieux aussi mais en pratique c'est pas génial )

la redhat 8.0 a une version pre2.3 ( 2.2.93 exactement ) , ca peut etre une piste

Tu as essayé NGPT 2 ? Ça m'intéresse un peu, tu as des précisions sur le « pas génial » ?

 
Pas le 2 non, je suis curieux aussi de le voir tourner, j'ai pas trop suivi mais apparement il est entierement posix et donne des perfs qui assassinent tout...
 
Je ne pensais pas que c'était déjà distribué, faudrait que je regarde ça.
 
Sinon pour la glibc 2.3, c'est un problème de header dans les include qui serait mauvais, c'est pas encore réglé mais on avance...

http://www-124.ibm.com/pthreads/
 
Niveau performances, je crois que LinuxThreads est déjà pas mal, surtout qu'il va profiter de la nouvelle VM dans le noyau 2.6 avec une gestion améliorée des processus, mais ça ne m'étonnerait pas qu'elles soient meilleures. C'est surtout la conformité POSIX qui m'intéresse, parce que LinuxThreads fait vraiment chier la bite avec les signaux.

Yep le site IBM je l'ai, par contre faut attendre le 2.6 pour profiter des perfs ?
 
Ula : pour glibc 2.3 y'a un bug de make, il se merde concernant le chemin des header, il les met dans /include au lieu du chemin voulu ( logiquement /usr/include pour beaucoup )
 
Ca pose un certain nombre de problèmes potentiels, nous apparement ça vient de ça, il faut modifier le config.make là :
 

Enculé de gars de la glibc qui pête plus haut que son cul :
 

 
MANGE CONNARD

oui on a essayé NGPT 2.0.1, pas de gros changement et surtout encore une gestion pas terrible du SMP (faut attendre des nouveaux patchs pour le kernel)

 
Merde j'ai confondu la version 2 avec un autre projet POSIX pour les threads
 
Y'avait une news y'a pas longtemps là dessus, faut que je retrouve

bon autre détail, si vous voulez compilez gcc, faut prendre une version snapshot de GCC 3.3, ca passera pas sur la 3.2 même en appliquant les patchs trouvés sur le net.
Autre truc marrant : ncurses compile plus (mais génère quand même les .a necessaire à la compil de mysql, qu'il faudra copier du rep ./lib au rep /usr/lib )

bon au final oubliez glibc-2.3 pour l'instant

joce a écrit a écrit : bon au final oubliez glibc-2.3 pour l'instant

 
"La malédiction de la glibc - Tome II"
 
Elle nous bouffera toujours des nuits celle là

clair vais me coucher moi  

Pas forcément, vu que la VM a déjà été améliorée dans le noyau 2.4. Le modèle d'ordonnancement de LinuxThreads est très simple, c'est pour ça que niveau perfs il déchire déjà bien.

non il confondait avec autre chose en fait

Sly Angel a écrit a écrit : Yep le site IBM je l'ai, par contre faut attendre le 2.6 pour profiter des perfs ?   Ula : pour glibc 2.3 y'a un bug de make, il se merde concernant le chemin des header, il les met dans /include au lieu du chemin voulu ( logiquement /usr/include pour beaucoup )   Ca pose un certain nombre de problèmes potentiels, nous apparement ça vient de ça, il faut modifier le config.make là :   [#f00e00]--- config.make.in      Wed Oct  9 02:19:00 2002[/#f00e00] [#0000ff]+++ config.make.in-edited     Wed Oct  9 02:19:33 2002[/#0000ff] @@ -17,6 +17,7 @@  libexecdir = @libexecdir@  rootsbindir = @libc_cv_rootsbindir@  infodir = @infodir@ [#0000f0]+includedir = @includedir@[/#0000f0]    # Should we use and build ldconfig?  use-ldconfig = @use_ldconfig@

thx ca doit etre pour ca qu'il ne trouvais pas le chemin
 
 
question subsidiere : tu trouve ou tes reponse ?

bluelightneon a écrit a écrit : thx ca doit etre pour ca qu'il ne trouvais pas le chemin     question subsidiere : tu trouve ou tes reponse ?

 
google et joce qui s'est inscrit sur la mailling debug glibc hier.
 
après c'est aussi te taper tous les fichiers à vérifier et regarder s'il se merde qq part.
 
Hier soir joce il était vachement motivé pour le faire

Sly Angel a écrit a écrit :     google et joce qui s'est inscrit sur la mailling debug glibc hier.   après c'est aussi te taper tous les fichiers à vérifier et regarder s'il se merde qq part.   Hier soir joce il était vachement motivé pour le faire

C l'habitude de se tapper des source a debuger
 
bah bizoo sur la fesse gauche de joce aussi
 
bon quand je serai motivé je la remet

bluelightneon a écrit a écrit : C l'habitude de se tapper des source a debuger   bah bizoo sur la fesse gauche de joce aussi   bon quand je serai motivé je la remet

 
Ouais enfin nous on a réussi à tout compilé après une nuit de batailles avec les bugs, les patchs, les versions, les headers...
 Ca n'a pas changé que MySQL se crashait en continu quand on le lançait ( et que ncurses voulait pas recompiler )
 
Donc bon...

Sly Angel a écrit a écrit :     google et joce qui s'est inscrit sur la mailling debug glibc hier.   après c'est aussi te taper tous les fichiers à vérifier et regarder s'il se merde qq part.   Hier soir joce il était vachement motivé pour le faire

nanan me suis pas inscrit à la mailing, j'ai juste décortiquer les fichiers makefile

ncurses compile toujours pas

joce a écrit a écrit : nanan me suis pas inscrit à la mailing, j'ai juste décortiquer les fichiers makefile

 
C'est pas une mailling les bugs report de glibc ?

non

 
t'as patché ?
 
il compilait pas non plus avec gcc 3.1/3.2 sans patch
 
moi j'ai pris celui de www.fr.linuxfromscratch.org

Sly Angel a écrit a écrit :     Ouais enfin nous on a réussi à tout compilé après une nuit de batailles avec les bugs, les patchs, les versions, les headers...  Ca n'a pas changé que MySQL se crashait en continu quand on le lançait ( et que ncurses voulait pas recompiler )   Donc bon...

donc je m'y mettrais quand je serai motiver et la Glibc en version 2.3.1
 
parcontre G pas eu de pb avec GCC et make