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

B . Carrupt bcapt at bluewin.ch
Fri Jul 18 23:30:03 CEST 2003


Parfait, merci pour ces explications qui dépassent mes espérances. Comme
quoi le support peut être tout aussi bon s'il est gratuit :)

Quant au problème, j'espère juste que ces corrections vont s'espacer, parce
que finalement si ça n'arrive qu'une fois toutes les cinq versions de gcc,
je saurais me démerder pour être à jour. Surtout en considérant le prix du
compilateur...





On 2003.07.18 19:42 Marc Mongenet wrote:
> B . Carrupt wrote:
> > Bonjour,
> > 
> > J'ai compilé sur ma RH7.2 des librairies au format ELF, et je me suis
> fait
> > un script qui les copie dans le répertoire /usr/lib/mylib.
> > 
> > Lorsque je crée un exécutable qui utilise ces librairies sur une RH7.2
> ou
> > RH7.3, ça fonctionne très bien, mais par contre, sur une RH8.0, ça ne
> > fonctionne pas : la librairie est bien trouvée mais pas les méthodes
> (ne
> > trouve aucune méthod, pas même le constructeur et le destructeur).
> > 
> > Par contre, dès que je recompile mes librairies sur RH8.0, ça
> fonctionne.
> 
> 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
> avec les versions précédentes. Spécifiquement, c'est l'ABI
> (Application Binary Interface) qui n'est pas compatible.
> <http://gcc.gnu.org/gcc-3.2/c++-abi.html>
> L'ABI comprend l'arrangement des variables dans les structures,
> la manière d'appeler les fonctions (virtuelles), la mise en oeuvre
> de l'héritage multiple... voir
> <http://developers.sun.com/tools/cc/articles/CC_abi/CC_abi_content.html>
> 
> L'incompatibilité la plus courante est dans le "name mangling"
> (décoration des noms de fonction). L'avantage de cette incompatibilité
> est qu'elle est détectée par le linker (il ne trouve pas les fonctions),
> plutôt que par un crash à l'exécution.
> 
> Les noms de fonction sont décorés avec le type des paramètres,
> ce qui donne un nom unique à chaque fonction, même surchargée.
> Ainsi le linker s'y retrouve, pour autant que l'algorithme de
> décoration employé soit le même pour tous les objets liés entre
> eux. Exemple :
> Function 		Mangled Name
> float f(float) 		__1cBf6Ff_f_
> int f(int) 		__1cBf6Fi_i_
> int T::f(int) 		__1cBTBf6Mi_i_
> int T::f(char*) 	__1cBTBf6Mpc_i_
> 
> Les variations de "name mangling" de G++ ne sont pas introduites
> gratuitement. Elles résultent de corrections de bugs et sont
> souvent nécessaires pour supporter le C++ standard (avec notamment
> ses namespaces, ses exceptions ou ses templates complexes).
> 
> > Est-ce que quelqu'un peut me dire si c'est normal, et si oui, s'il y a
> un
> > moyen de garder la compatibilité entre plusieurs version de RH, voire
> entre
> > une version de RH et une version plus récente de Suze ou Mandrake ou
> > Quesaije ?
> 
> Je pense que non, sinon ces évolutions n'auraient pas été
> nécessaires. Mais une ABI multi-vendeur se stabilise
> <http://www.codesourcery.com/cxx-abi/>
> Ces problèmes devraient donc s'espacer. En outre il sera
> possible de lier des fichiers objets de compilateurs C++
> différents, ça progresse !
> 
> Marc
> 
> _______________________________________________
> gull mailing list
> gull at lists.alphanet.ch
> http://lists.alphanet.ch/mailman/listinfo/gull
> 




More information about the gull mailing list