Bonjour,

J'ai réalisé un petit programme cross-compilé sous win32 et linux. Il a toujours fonctionné sans problème chez mes clients mais là soudainement j'ai eu cette erreur sur un red hat 5.5 en 64 bits.

Voici les dépendances :

[root@bt1svl2h Clustering]# ldd cluster
./cluster: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./cluster)
linux-gate.so.1 => (0xffffe000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00805000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf7e87000)
libm.so.6 => /lib/libm.so.6 (0x00827000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7e7b000)
libc.so.6 => /lib/libc.so.6 (0x006ab000)
/lib/ld-linux.so.2 (0x0068c000)

Or, si l'on regarde avec cette commande les versions supportées actuellement pour libstdc sur cet os:

[root@bt1svl2h Clustering]# rpm -q --provides libstdc++
libstdc++ = 4.1.1-52.el5
libstdc++.so.6()(64bit)
libstdc++.so.6(CXXABI_1.3)(64bit)
libstdc++.so.6(CXXABI_1.3.1)(64bit)
libstdc++.so.6(GLIBCXX_3.4)(64bit)
libstdc++.so.6(GLIBCXX_3.4.1)(64bit)
libstdc++.so.6(GLIBCXX_3.4.2)(64bit)
libstdc++.so.6(GLIBCXX_3.4.3)(64bit)
libstdc++.so.6(GLIBCXX_3.4.4)(64bit)
libstdc++.so.6(GLIBCXX_3.4.5)(64bit)
libstdc++.so.6(GLIBCXX_3.4.6)(64bit)
libstdc++.so.6(GLIBCXX_3.4.7)(64bit)
libstdc++.so.6(GLIBCXX_3.4.8)(64bit)
libstdc++ = 4.1.2-48.el5
libstdc++ = 4.1.1-52.el5
libstdc++.so.6
libstdc++.so.6(CXXABI_1.3)
libstdc++.so.6(CXXABI_1.3.1)
libstdc++.so.6(GLIBCXX_3.4)
libstdc++.so.6(GLIBCXX_3.4.1)
libstdc++.so.6(GLIBCXX_3.4.2)
libstdc++.so.6(GLIBCXX_3.4.3)
libstdc++.so.6(GLIBCXX_3.4.4)
libstdc++.so.6(GLIBCXX_3.4.5)
libstdc++.so.6(GLIBCXX_3.4.6)
libstdc++.so.6(GLIBCXX_3.4.7)
libstdc++.so.6(GLIBCXX_3.4.8)
libstdc++ = 4.1.2-48.el5

Visiblement, la version de libstdc++ est trop ancienne. Et il n'est pas possible pour le client d'upgrader pour des raisons de politique de garantie red hat.

et je ne sais malheureusement pas comment je peux maximiser la compatibilité de mon délivrable pour être sûr qu'il fonctionne sur ce vieux système. Il me semble que ce ne soit pas possible de le faire à la compilation au moyen d'un flag. Donc ma chance serait d'installer une vieille croûte de linux sur une VM et de re-compiler mais comment savoir quel est l'environnement qui offre le plus de compatibilité?

Je pensais utiliser une debian lenny qui est très populaire chez mes clients comme machine de build, mais même là je ne vois pas trop comment m'assurer que je suis compatible en 3.4.8.
Bref j'avoue que j'y vois pas trop clair et que je suis pas sûr de comment assurer. Y'a plein de gens qui reportent ce genre de problème sur le net mais très peu de solutions claires.

Si quelqu'un a une piste ou un conseil...

quid du linkage statique?

Pas sûr que ce soit souhaitable...
Sinon il me semble avoir réussi en installant une ancienne version de g++.

godrik a raison. Si la machine n'est pas à jour, rien n'est souhaitable. Le linkage statique devient donc un moindre mal.

Ca ne risque pas de faire déconner certaines fonctionnalités?

Je link statiquement ma libc pour linux quand je compile des binaires natifs pour android et je n'ai eu que des bugs mineur (principalement lie a la date dont la gestion des locales est differente).

Donc j'ai envie de dire que tu es tranquil

_skip: si ton code est compatible avec les librairies que tu utilises pour compiler (et le contraire serait étonnant ), il n'y a pas de soucis à part la taille du binaire.

il faut penser au dependences externe egalement, genre si tu as besoin de te connecte a une base mysql, tu peux avoir envie de garder les dependences a la libmysql dynamique pour conserver la compatibilite ascendente.