[gull] ELF non compatibles entre RH7.2 et RH8.0

[Marc Mongenet]

Marc SCHAEFER wrote:
> 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