Différences entre versions de « Compatibilité binaire »

De Cliss XXI
Sauter à la navigation Sauter à la recherche
 
(12 versions intermédiaires par 2 utilisateurs non affichées)
Ligne 21 : Ligne 21 :
 
== Questions ==
 
== Questions ==
  
−
=== Comment se fait-il qu'un différence the 3 millième de version (2.3.2->2.3.5) puisse occasionner un plantage? ===
+
=== Comment se fait-il qu'un différence the 4 millièmes de version (2.3.2->2.3.6) puisse occasionner un plantage? ===
  
−
La libc6 powerpc de etch contient un symbole ''GLIBC_2.3.4 setjmp'':
+
La libc6 powerpc de etch (2.3.6-13) contient un symbole ''GLIBC_2.3.4 setjmp'':
  
 +
$ objdump -T /lib/libc.so.6 | grep setjmp
 
  00032f88 g    DF .text  00000008  GLIBC_2.3.4 setjmp
 
  00032f88 g    DF .text  00000008  GLIBC_2.3.4 setjmp
 
  00032f90 g    DF .text  00000008 (GLIBC_2.0)  _setjmp
 
  00032f90 g    DF .text  00000008 (GLIBC_2.0)  _setjmp
Ligne 32 : Ligne 33 :
 
  00032f80 g    DF .text  00000008 (GLIBC_2.0)  setjmp
 
  00032f80 g    DF .text  00000008 (GLIBC_2.0)  setjmp
  
−
Mais avec testing:
+
Mais avec sarge (2.3.2.ds1-22sarge3):
 +
00032780 g    DF .text  00000008  GLIBC_2.0  setjmp
 +
00032668 g    DF .text  000000a8  GLIBC_2.0  __sigsetjmp
 +
00032788 g    DF .text  00000008  GLIBC_2.0  _setjmp
  
 +
Donc en compilant sous etch, on utilise le symbole estampillé "2.3.4" - qui n'est malheureusement pas dans la version de sarge.
  
 +
C'est expliqué en détail [http://autopackage.org/docs/devguide/ch07.html#id2529304 ici].
 +
 +
La solution préconisée par autopackage est de recompiler avec une vielle libc - donc avec compatibilité arrière.
  
 
=== Et comment MS Woe évite-t-il ce problème? ===
 
=== Et comment MS Woe évite-t-il ce problème? ===
Ligne 41 : Ligne 49 :
  
 
Probablement en gelant sa libc et msvcrt.dll.
 
Probablement en gelant sa libc et msvcrt.dll.
 +
 +
Il faut garder à l'esprit que Woe est conçu pour faire tourner de ''vieux'' exécutables dont on a probablement perdu le code source - la compatibilité binaire a donc été prise beaucoup plus au sérieux qu'avec GNU/Linux.
 +
 +
Ah tiens ben non: [http://bytes.com/topic/python/answers/454315-python-2-4-2-using-msvcrt71-dll-win-compatibility-issues Python 2.4.2 using msvcrt71.dll on Win and compatibility issues] - deux versions de msvcrt ne sont pas compatibles, et si deux bibliothèques de votre projet ont été compilées avec deux versions différentes, vous vous prenez une erreur de segmentation.
 +
 +
Microsoft [http://support.microsoft.com/kb/326922 recommande] de distribuer une copie distincte de msvcrt avec chaque application, et de l'installer dans le répertoire de l'application plutôt qu'au niveau système. Cette approche ne résoud pas le problème ci-dessus et est inefficace au niveau suivi de sécurité (les bibliothèques peuvent être facilement mises à jour au niveau système, mais pas au niveau application).
 +
 +
[http://msdn.microsoft.com/en-us/library/abx4dbyh%28VS.71%29.aspx Cette page] indique qu'il est possible d'utilise le switch <code>/MD</code> qui apparemment sélectionne une version précise de la bibliothèque CRT - sans cependant corriger tous les conflicts.
 +
 +
Bref le problème reste entier.
 +
 +
=== Pourquoi sur PowerPC? ===
 +
 +
Sur un AMD32/etch:
 +
$ objdump -T /lib/libc.so.6 | grep setjmp
 +
00029210 g    DF .text  00000038  GLIBC_2.0  setjmp
 +
00029170 g    DF .text  0000002f  GLIBC_2.0  __sigsetjmp
 +
00029250 g    DF .text  00000022  GLIBC_2.0  _setjmp
 +
 +
Il s'agit de la même version, donc pas de problème.
  
 
== Autre problème à élucider ==
 
== Autre problème à élucider ==
Ligne 52 : Ligne 80 :
 
* [http://www.trilithium.com/johan/2005/06/static-libstdc/ Linking ilbstdc++ statically]: libstdc++ and cascading loading issues explained
 
* [http://www.trilithium.com/johan/2005/06/static-libstdc/ Linking ilbstdc++ statically]: libstdc++ and cascading loading issues explained
 
* http://www.kernel.org/pub/software/libs/glibc/hjl/compat/
 
* http://www.kernel.org/pub/software/libs/glibc/hjl/compat/
 +
* [http://people.redhat.com/drepper/symbol-versioning ELF symbol versioning with glibc 2.1 and later]: symbol-level versioning implementation details
 +
* [http://www.gnu.org/software/libc/FAQ.html#s-1.17 What is symbol versioning good for? Do I need it?], from the glibc FAQ
 +
* [http://people.redhat.com/drepper/no_static_linking.html Static Linking Considered Harmful]: static linking is not an option either
 +
* [http://plan99.net/~mike/writing-shared-libraries.html Writing shared libraries]: conseils pour l'écriture de bibliothèques de fonctions respectant la compatibilité arrière

Version actuelle datée du 2 mai 2010 à 10:14

Le problème: je ne peux pas prendre un paquet testing et l'installer sur stable, dans le cas où si la seule dépendance est la libc.

Reproduction du problème

Configuration: une Debian PPC (cf. Émulation)

  • libc6 2.3.2.ds1-22sarge3
  • libneon24 0.24.7.dfsg-2

On force l'installation de tla/testing/20060624, ie tla_1.3.3-3_powerpc (Depends: libc6 (>= 2.3.5-1), libneon24 (>= 0.24.7.dfsg), diff (>= 2.8.1), patch (>= 2.5.9), gawk). 

dpkg -i --force-all tla_1.3.3-3_powerpc.deb

$ tla --version
tla-1.3.3-2
[...]
$ tla register-archive http://vcs.patapouf.org/arch/
Registering archive: devel@patapouf.org--patapouf-arch
$ tla get devel@patapouf.org--patapouf-arch/gcourrier--mainline--1.0
tla: relocation error: tla: symbol _setjmp, version GLIBC_2.3.4 not defined in file libc.so.6 with link time reference

Questions

Comment se fait-il qu'un différence the 4 millièmes de version (2.3.2->2.3.6) puisse occasionner un plantage?

La libc6 powerpc de etch (2.3.6-13) contient un symbole GLIBC_2.3.4 setjmp: 

$ objdump -T /lib/libc.so.6 | grep setjmp
00032f88 g    DF .text  00000008  GLIBC_2.3.4 setjmp
00032f90 g    DF .text  00000008 (GLIBC_2.0)  _setjmp
00032e3c g    DF .text  000000a8 (GLIBC_2.0)  __sigsetjmp
00032c20 g    DF .text  0000021c  GLIBC_2.3.4 __sigsetjmp
00032fa0 g    DF .text  00000008  GLIBC_2.3.4 _setjmp
00032f80 g    DF .text  00000008 (GLIBC_2.0)  setjmp

Mais avec sarge (2.3.2.ds1-22sarge3): 

00032780 g    DF .text  00000008  GLIBC_2.0   setjmp
00032668 g    DF .text  000000a8  GLIBC_2.0   __sigsetjmp
00032788 g    DF .text  00000008  GLIBC_2.0   _setjmp

Donc en compilant sous etch, on utilise le symbole estampillé "2.3.4" - qui n'est malheureusement pas dans la version de sarge.

C'est expliqué en détail ici.

La solution préconisée par autopackage est de recompiler avec une vielle libc - donc avec compatibilité arrière.

Et comment MS Woe évite-t-il ce problème?

J'aimerais bien le savoir...

Probablement en gelant sa libc et msvcrt.dll.

Il faut garder à l'esprit que Woe est conçu pour faire tourner de vieux exécutables dont on a probablement perdu le code source - la compatibilité binaire a donc été prise beaucoup plus au sérieux qu'avec GNU/Linux.

Ah tiens ben non: Python 2.4.2 using msvcrt71.dll on Win and compatibility issues - deux versions de msvcrt ne sont pas compatibles, et si deux bibliothèques de votre projet ont été compilées avec deux versions différentes, vous vous prenez une erreur de segmentation.

Microsoft recommande de distribuer une copie distincte de msvcrt avec chaque application, et de l'installer dans le répertoire de l'application plutôt qu'au niveau système. Cette approche ne résoud pas le problème ci-dessus et est inefficace au niveau suivi de sécurité (les bibliothèques peuvent être facilement mises à jour au niveau système, mais pas au niveau application).

Cette page indique qu'il est possible d'utilise le switch /MD qui apparemment sélectionne une version précise de la bibliothèque CRT - sans cependant corriger tous les conflicts.

Bref le problème reste entier.

Pourquoi sur PowerPC?

Sur un AMD32/etch: 

$ objdump -T /lib/libc.so.6 | grep setjmp
00029210 g    DF .text  00000038  GLIBC_2.0   setjmp
00029170 g    DF .text  0000002f  GLIBC_2.0   __sigsetjmp
00029250 g    DF .text  00000022  GLIBC_2.0   _setjmp

Il s'agit de la même version, donc pas de problème.

Autre problème à élucider


Liens

Récupérée de « https://doc.cliss21.com/index.php?title=Compatibilité_binaire&oldid=1643 »