2011-09-28 4 views
2

J'utilise un tiers bibliothèque partagée (libsw_api.so) sur Solaris, qui lorsque je tente de charger, produit l'erreur suivante:Quelle version de libstdC++. So.6 utiliser?

fatal: relocation error: file libsw_api.so: 
symbol _ZNKSt9bad_alloc4whatEv: referenced symbol not found 
The program exited with error code 1 

Quand je lance ldd sur libsw_api.so, toutes les références semblent à remplir, en particulier la bibliothèque standard C++ qui pointe vers libstdC++ so.6.0.3:.

glispa02(fostopr)$ ldd libsw_api.so 
... 
libstdc++.so.6 =>  /usr/sfw/lib/libstdc++.so.6 
... 
glispa02(fostopr)$ ls -l /usr/sfw/lib/libstdc++.so.6 
lrwxrwxrwx 1 root  root   18 Jun 21 2010 /usr/sfw/lib/libstdc++.so.6 -> libstdc++.so.6.0.3 

Cependant cette bibliothèque n'exporte pas _ZNKSt9bad_alloc4whatEv,

glispa02(fostopr)$ nm /usr/sfw/lib/libstdc++.so.6 | grep bad_alloc       
[7592] | 752340|  64|FUNC |GLOB |0 |2653 |_ZNSt9bad_allocD0Ev 
[7324] | 752284|  56|FUNC |GLOB |0 |2652 |_ZNSt9bad_allocD1Ev 
[8077] | 752228|  56|FUNC |GLOB |0 |2651 |_ZNSt9bad_allocD2Ev 
[7519] | 356736|  76|FUNC |GLOB |0 |473 |_ZSt17__throw_bad_allocv 
[7341] | 983588|  12|OBJT |WEAK |0 |3842 |_ZTISt9bad_alloc 
[6569] | 777008|  13|OBJT |WEAK |0 |3317 |_ZTSSt9bad_alloc 
[7299] | 983568|  20|OBJT |WEAK |0 |3841 |_ZTVSt9bad_alloc 

Quel pourrait être le problème? Mauvaise version? Je ne suis pas vraiment bon avec C++ sur Unix donc j'apprécierais toute aide.

Cette incompatibilité entre SPARC32PLUS et SPARC peut-elle être à l'origine du problème?

glispa02(fostopr)$ file libsw_api.so   
libsw_api.so: ELF 32-bit MSB dynamic lib SPARC32PLUS Version 1, V8+ Required, dynamically linked, not stripped 
glispa02(fostopr)$ file /usr/sfw/lib/libstdc++.so.6.0.3 
/usr/sfw/lib/libstdc++.so.6.0.3:  ELF 32-bit MSB dynamic lib SPARC Version 1, dynamically linked, not stripped, no debugging information available 

Mon système:

glispa02(fostopr)$ cat /etc/release      
        Solaris 10 10/09 s10s_u8wos_08a SPARC 
     Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. 
        Use is subject to license terms. 
         Assembled 16 September 2009 
glispa02(fostopr)$ uname -a 
SunOS glispa02 5.10 Generic_141444-09 sun4u sparc SUNW,SPARC-Enterprise 
+0

Je me demande si un libstdC++ a 'bad_alloc :: what' inline au lieu des en-têtes et libsw_api a été compilé avec un autre libstdC++. –

+0

Peut-être qu'avec des paramètres d'optimisation différents, la source de l'OP se compilera avec 'what()' inlined? Juste une conjecture sauvage ... –

Répondre

0

Si vous utilisez pvs sur le fichier libstdc++.so.6, il vous donnera un tas d'entrées correspondantes: GLIBCXX, si vous ne disposez pas d'entrée correspondant à GLIBCXX_3.4.9, puis le symbole bad_alloc::what ne se trouve pas dans cette bibliothèque, c'est-à-dire que la bibliothèque est plus ancienne que l'objet dépendant libsw_api.so

Si c'est le cas, alors vous avez probablement besoin d'une version plus récente de libstdC++ - ce serait viens avec une version plus récente de g ++

+0

sortie pvs: 'libgcc_s.so.1 (GCC_3.3);' et 'libc.so.1 (SUNW_1.22, SUNWprivate_1.1);'. Je vais essayer de mettre à jour g ++, merci! – Martin

+0

Je pense que je comprends mieux votre commentaire maintenant, vous voulez savoir quelles interfaces 'libstdC++. So.6' fournit, pas de quoi il dépend, non? Quand je fais 'pvs -d/usr/sfw/lib/libstdC++. So.6' je ne reçois aucune sortie du tout. Pourquoi? – Martin

2

Salut, je suis également en train de mettre à jour ces fichiers, j'ai remarqué que je devrais utiliser le fichier libstdC++. so.6.0.9 fourni avec la distribution plutôt que celui de/usr/sfw/lib/

0

Je rencontre le même problème.

La cause est que nous exportons le mauvais LD_LIBRARY_PATH Alors que notre bibliothèque partagée lie à la bibliothèque originale de gcc (3.3) au lieu de notre compilateur (gcc 4.4).

résoudre le problème de linker devrait résoudre le problème

Questions connexes