J'ai du code qui fonctionne bien, mais si je liez mon projet à une tierce partie libabc.so code> (source indisponible), alors tout soudain, je reçois une défaillance de segmentation.
J'ai une principale qui ressemble à ce p> le CMAKelist.txt est comme suit p> Thread 1 "my_project" received signal SIGSEGV, Segmentation fault.
0x00007fdea96836b3 in png_destroy_write_struct () from /usr/local/lib/libabc.so
3 Réponses :
Je suppose que c'est le problème?
Oui: c'est très probable:
libabc.so est lié statilement (version probablement différente de)libpng et introduit le conflit de symboles.Je ne veux pas que Opencv soit voir les exportations libabc.so ... Comment puis-je faire cela?
Vous ne pouvez pas. Vous devez contacter
libabc.so développeur et dites-leur de masquerlibpng symboles.La seule autre option (pour l'exécution de processus unique) consiste à charger dynamiquement
libabc.so .Ceci peut être fait via
dlopen ("LIABC.SO.", RTLD_LOCAL) , et même cela peut ne pas fonctionner (selon exactement commentlibabc.so était lié ) - Il peut causerlibabc.so pour se lier à votre version delibpng et crash.sur Linux, vous pouvez également utiliser
dlmopen (lm_id_newlm, "libabc.so", ...) qui va complètement isolerlibabc.so < / code> à partir du reste de votre code et mai travail silibabc.so était lié à inclure toutes ses dépendances (ou vous pouvez les amener à l'espace de nom de chargeur explicitement).Enfin, comme Eljay a commenté ici, vous pouvez utiliser la communication inter-processus et avoir une charge de processus complètement distincte
libabc.so . Cela aura une performance bien pire que d'utiliserlibabc.so directement, mais c'est mieux que rien.
Merci pour votre réponse. Serait-il possible d'une manière ou d'une autre de créer mon wrapper autour de libabc.so de sorte que je masque / expose manuellement certaines des méthodes (par exemple, seulement celles de "ABC.H") et de lier contre ce nouveau wrapper ?
@Alwld "serait-il possible ...". Non.
Ce serait possible, mais cela implique de l'exécuter hors processus et d'utiliser une communication interprocessée.
Pourquoi ne pas mentionner la modification manuelle de .dynsym comme mentionné dans votre Autre réponse ?
@YUGR L'autre réponse ( Stackoverflow.com/Questtions/36273404/... ) ne s'applique que lorsque vous pouvez relier le .so . Modification .so est susceptible de provoquer des tables de hachage de devenir incompatibles, ce qui entraîne un blocage dans ld-linux .
Je voudrais essayer bande . Voir ceci pour plus de détails: https://linux.die.net/man/1/stripide/ a>
bande fait rien pour les tables de symboles dynamiques.
Pour ajouter à la réponse de EmployeRussien sur l'utilisation de DLMOPEN CODE>-BASED APPROCHE POUR ISOLER LIBABC.SO à partir du reste de votre code: Pour éviter de jouer avec DLSYM code> et des pointeurs de fonction dans ce Case, vous pouvez générer automatiquement des emballages pour les fonctions de la bibliothèque nécessaires via Implib.so : $ cat mysymbols.txt
foo
bar
$ cat mycallback.c
#define _GNU_SOURCE
#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>
#ifdef __cplusplus
extern "C"
#endif
// Dlopen callback that loads library to dedicated namespace
void *mycallback() {
void *h = dlmopen(LM_ID_NEWLM, "libabc.so", RTLD_LAZY | RTLD_DEEPBIND);
if (h)
return h;
fprintf(stderr, "dlmopen failed: %s\n", dlerror());
exit(1);
}
$ implib-gen.py --dlopen-callback=mycallback --symbol-list=mysymbols.txt libabc.so
$ ... # Link your app with libabc.tramp.S, libabc.init.c and mycallback.c