On Fri, Jul 18, 2003 at 07:42:50PM +0200, Marc Mongenet wrote:
Cela vient sans doute du fait d'un changement de version de GCC. Les fichiers objets compil�s avec G++ 3.2.x ne sont pas compatibles
Est-ce li� au fait que i386 ne sera plus support� compl�tement ?
Non, voici une illustration du probl�me :
# cat >hello.c
const char * hello() { return "hello"; }# gcc -c hello.c # nm hello.o | grep hello 00000000 T hello # cp hello.c hello.cc # g++ -v Lecture des sp�cification � partir de /home/marc/Soft/lib/gcc-lib/i686-pc-linux-gnu/3.3/specs Configur� avec: ../gcc-3.3/configure --prefix=/home/marc/Soft Mod�le de thread: posix version gcc 3.3 # g++ -c hello.cc # nm hello.o | grep hello 00000000 T _Z5hellov # /usr/bin/g++ -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs gcc version 2.95.4 20011002 (Debian prerelease) # /usr/bin/g++ -c hello.cc # nm hello.o | grep hello 00000000 T hello__Fv #
Comme on voit, le linker va trouver dans hello.o le symbole "hello" avec une compilation C, mais "_Z5hellov" ou "hello__Fv" selon la version de g++ utilis�e.
> J'ai eu lu que Debian devra renoncer bient�t � supporter les 386 pour ne
supporter que 486, 586 et sup�rieurs (justement en raison de changements incompatibles dans la libc et de la n�cessit� de rester compatible avec les autres distributions).
R�f�rence: http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01895.html
- In gcc-3.3, it's differentiated between i386 and ix86 (>=4), however the atomicity implementation is selected at configure time (so an i386-linux configured compiler always uses the generic implementation).
- Trying to "fix" this resulted in libstdc++5 packages built for i386 and ix86, and selecting the atomicity implementation based on target cpu macros. This approach doesn't work, as I learned now. See http://gcc.gnu.org/ml/libstdc++/2003-04/msg00394.html: It's not possible to mix the two implementations.
Je ne connaissais pas ces faits, ils sont int�ressants. Ils d�crivent cependant un probl�me tout diff�rent : Le fichier include/c++/3.3/i686-pc-linux-gnu/bits/atomicity.h (chez moi) contient des impl�mentations assembleur de __exchange_and_add et __atomic_add qui ne sont pas impl�ment�es de la m�me fa�on selon que le compilateur soit configur� (./configure en installant GCC je suppose) pour i386 ou i486+. Ces deux impl�mentations sont incompatibles.
Cette incompatibit� ne serait pas g�nante s'il n'existait qu'une instance (dans la libstdc++) par programme des fonctions de atomicity.h. Mais cette incompatibilit� est dans un fichier include et peut �tre compil�e inline dans chaque fichier objet (comme c'est souvent le cas en C++). Il y a donc donc probl�me si tous les fichiers n'ont pas �t� compil� avec des GCC identiquement configur�s.
En r�sum�, d'apr�s <http://gcc.gnu.org/ml/libstdc++/2003-04/msg00394.html> : "BTW, yes, IMHO, we've been screwed by using a C atomicity ABI in our C++ library in a manner that exposes the details of the implementation in headers used directly by users"
Cela dit, je pense que le i386 sera encore support� des ann�es, voire des d�cennies, par GCC. Les architectures qui ne seront plus support�es par GCC 3.4 sont Matsushita MN10200 mn10200-*-*, Motorola 88000 m88k-*-* et IBM ROMP romp-*-*; rien de tr�s populaire... <http://gcc.gnu.org/gcc-3.4/changes.html>
Dommage, j'aime bien recycler des 386 et 486 en routeurs/firewall cable/ADSL sous Debian. C'�tait � peu pr�s la derni�re distribution `mainstream' � supporter ce mat�riel.
Ce qui serait bien, c'est une distribution i386 et une i686. �videmment la distribution i386 fonctionnerait sur 486, 586, 686 et 786, mais pour les 686 et 786 elle serait plus lente que la i686. Debian a d�j� tellement de distributions qui sont sans doute moins utilis�es que ne le serait une i386 que cela ne poserait sans doute pas de probl�me majeur.
Marc Mongenet
_______________________________________________ gull mailing list [EMAIL PROTECTED] http://lists.alphanet.ch/mailman/listinfo/gull
