Compatibilité binaire

De Cliss XXI
Sauter à la navigation Sauter à la recherche

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 »