Différences entre versions de « Compatibilité binaire »

De Cliss XXI
Sauter à la navigation Sauter à la recherche
imported>SylvainBeucler
m (canonical url instead of ML post)
imported>SylvainBeucler
m
Ligne 74 : Ligne 74 :
 
* [http://people.redhat.com/drepper/symbol-versioning ELF symbol versioning with glibc 2.1 and later]: symbol-level versioning implementation details
 
* [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://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

Version du 25 juin 2006 à 14:38

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.

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