Hé, dites, vous avez vu, le dingue qui pilote SCO a dit qu'il allait
casser l'arangemet à l'amiable USL vs Berkeley concernant les sources de
BSD. Je me demande si SCO a fait le ménage dans les sources d'UNIX
System V pour re-attribuer toutes les notices de copyright BSD qui
avaient disparu à l'epoque.
Cette affaire est incroyable: alors qu'on se dit qu'il sont allés au
bout et qu'ils ne peuvent pas délirer plus loin, ils trouvent encore une
idée de procès à faire. Quelle créativité!
--
Emmanuel Dreyfus
A lire: 240 pages en français sur l'administration UNIX avec BSD
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
OoO En ce début d'après-midi ensoleillé du vendredi 21 novembre 2003, vers 15:16, (Xavier) disait:
- Il reste plein de Gnuteries dans BSD, ergo dans Darwin/MacOSX. Le front-end d'IBM est -il compatible ? Quand on voit que la secte s'amuse à changer l'ABI C++ entre la 3.2 et la 3.3...
Hein ?
Faut pas faire attention, c'est juste Xavier qui a vu des modifs entre gcc 3.2 et gcc 3.3.
Mais bon, il faut voir que l'ABI C++ a change de maniere tres frequente dans toutes les versions de gcc. Ce n'est que recemment que les choses ont ete standardisees, et il y a eu d'enormes discussions au sujet des changements entre gcc 3.2 et gcc 3.3.
Essentiellement, les `changements' en question sont des corrections de bug pour, justement, correspondre a la norme de l'ABI.
Rien que le fait que le probleme ait ete proprement aborde est un progres enorme par rapport a ce qui se faisait de maniere anterieure. Il y a maintenant une vraie politique de gestion des versions et de la stabilite au niveau de gcc (bon, la qualite n'est pas toujours au rendez-vous, surtout cote vitesse du compilo, mais certains trucs se sont un peu ameliores).
Si je me place, une fois n'est pas coutume, du cote des gens qui font gcc, ils n'ont aucune chance de s'en sortir. - soit ils ne changent pas l'ABI de g++, et alors Xavier va nous dire que gcc fait du code buggue. - soit ils changent l'ABI de g++, et alors Xavier vient de nous dire qu'ils changent tout le temps les ABI, qu'on n'y peut rien.
Non, a mon avis, si probleme il y a, il vient plutot des sacro-saintes manies de compatibilite binaire a la gnu/linux, ou leurs modifs de glibc au moment de libc5->libc6 ont ete gerees de maniere calamiteuse, et a leurs plans de compatibilite binaire depuis qui sont totalement incomprehensibles (quelqu'un capte quelque chose au versioning des symboles dans la glibc ?)
Il faut bien se faire a l'idee que, de temps en temps, il faut casser la compatibilite binaire.
-- Marc, qui vient de passer le week-end a upgrader sa libiberty de systeme a la version livree avec gcc 3.3.2, et qui s'essaie a preparer la migration vers gcc 3.3.2 sur certaines plateformes...
so far, so good, ca marche dix fois mieux que pour gcc 2.95.x.
In article <m3vfpdhytv.fsf@neo.loria>,
Vincent Bernat <vincent.bernat@raysa.org> wrote:
OoO En ce début d'après-midi ensoleillé du vendredi 21 novembre 2003,
vers 15:16, xavier@groumpf.org (Xavier) disait:
- Il reste plein de Gnuteries dans BSD, ergo dans Darwin/MacOSX. Le
front-end d'IBM est -il compatible ? Quand on voit que la secte s'amuse
à changer l'ABI C++ entre la 3.2 et la 3.3...
Hein ?
Faut pas faire attention, c'est juste Xavier qui a vu des modifs entre
gcc 3.2 et gcc 3.3.
Mais bon, il faut voir que l'ABI C++ a change de maniere tres frequente
dans toutes les versions de gcc. Ce n'est que recemment que les choses
ont ete standardisees, et il y a eu d'enormes discussions au sujet des
changements entre gcc 3.2 et gcc 3.3.
Essentiellement, les `changements' en question sont des corrections de bug
pour, justement, correspondre a la norme de l'ABI.
Rien que le fait que le probleme ait ete proprement aborde est un progres
enorme par rapport a ce qui se faisait de maniere anterieure. Il y a
maintenant une vraie politique de gestion des versions et de la stabilite
au niveau de gcc (bon, la qualite n'est pas toujours au rendez-vous,
surtout cote vitesse du compilo, mais certains trucs se sont un peu
ameliores).
Si je me place, une fois n'est pas coutume, du cote des gens qui font gcc,
ils n'ont aucune chance de s'en sortir.
- soit ils ne changent pas l'ABI de g++, et alors Xavier va nous dire que
gcc fait du code buggue.
- soit ils changent l'ABI de g++, et alors Xavier vient de nous dire qu'ils
changent tout le temps les ABI, qu'on n'y peut rien.
Non, a mon avis, si probleme il y a, il vient plutot des sacro-saintes
manies de compatibilite binaire a la gnu/linux, ou leurs modifs de glibc
au moment de libc5->libc6 ont ete gerees de maniere calamiteuse, et a leurs
plans de compatibilite binaire depuis qui sont totalement incomprehensibles
(quelqu'un capte quelque chose au versioning des symboles dans la glibc ?)
Il faut bien se faire a l'idee que, de temps en temps, il faut casser la
compatibilite binaire.
--
Marc, qui vient de passer le week-end a upgrader sa libiberty de
systeme a la version livree avec gcc 3.3.2, et qui s'essaie a
preparer la migration vers gcc 3.3.2 sur certaines plateformes...
so far, so good, ca marche dix fois mieux que pour gcc 2.95.x.
OoO En ce début d'après-midi ensoleillé du vendredi 21 novembre 2003, vers 15:16, (Xavier) disait:
- Il reste plein de Gnuteries dans BSD, ergo dans Darwin/MacOSX. Le front-end d'IBM est -il compatible ? Quand on voit que la secte s'amuse à changer l'ABI C++ entre la 3.2 et la 3.3...
Hein ?
Faut pas faire attention, c'est juste Xavier qui a vu des modifs entre gcc 3.2 et gcc 3.3.
Mais bon, il faut voir que l'ABI C++ a change de maniere tres frequente dans toutes les versions de gcc. Ce n'est que recemment que les choses ont ete standardisees, et il y a eu d'enormes discussions au sujet des changements entre gcc 3.2 et gcc 3.3.
Essentiellement, les `changements' en question sont des corrections de bug pour, justement, correspondre a la norme de l'ABI.
Rien que le fait que le probleme ait ete proprement aborde est un progres enorme par rapport a ce qui se faisait de maniere anterieure. Il y a maintenant une vraie politique de gestion des versions et de la stabilite au niveau de gcc (bon, la qualite n'est pas toujours au rendez-vous, surtout cote vitesse du compilo, mais certains trucs se sont un peu ameliores).
Si je me place, une fois n'est pas coutume, du cote des gens qui font gcc, ils n'ont aucune chance de s'en sortir. - soit ils ne changent pas l'ABI de g++, et alors Xavier va nous dire que gcc fait du code buggue. - soit ils changent l'ABI de g++, et alors Xavier vient de nous dire qu'ils changent tout le temps les ABI, qu'on n'y peut rien.
Non, a mon avis, si probleme il y a, il vient plutot des sacro-saintes manies de compatibilite binaire a la gnu/linux, ou leurs modifs de glibc au moment de libc5->libc6 ont ete gerees de maniere calamiteuse, et a leurs plans de compatibilite binaire depuis qui sont totalement incomprehensibles (quelqu'un capte quelque chose au versioning des symboles dans la glibc ?)
Il faut bien se faire a l'idee que, de temps en temps, il faut casser la compatibilite binaire.
-- Marc, qui vient de passer le week-end a upgrader sa libiberty de systeme a la version livree avec gcc 3.3.2, et qui s'essaie a preparer la migration vers gcc 3.3.2 sur certaines plateformes...
so far, so good, ca marche dix fois mieux que pour gcc 2.95.x.
