Différences entre versions de « Compatibilité binaire »
imported>SylvainBeucler m (→Liens) |
imported>SylvainBeucler m (canonical url instead of ML post) |
||
| Ligne 72 : | Ligne 72 : | ||
* [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:// | + | * [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 | ||
Version du 25 juin 2006 à 14:32
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
- http://lists.dccalliance.org/pipermail/dcc-devel/2005-October/000280.html: backport OpenOffice2 pour DCC.
Liens
- Binary portability, from the Autopackage Packagers Guide
- Linking ilbstdc++ statically: libstdc++ and cascading loading issues explained
- http://www.kernel.org/pub/software/libs/glibc/hjl/compat/
- ELF symbol versioning with glibc 2.1 and later: symbol-level versioning implementation details
- What is symbol versioning good for? Do I need it?, from the glibc FAQ