j'ai rapatrié la version SVN de Scribus. Elle compile sans problèmes,
une fois que l'on a installé « cmake » et cups. Cependant, au lancement,
le programme principal ne peut charger aucun greffon (/plugin/). À
chaque essai, j'obtiens un message d'erreur « symbole non défini » pour
deux symboles C++ particuliers.
Impossible de trouver l'extension:
/usr/pkg/scribus135/lib/scribus/plugins//libscriptplugin.so: Undefined
symbol "_ZTI13UpdateMemento" (symnum = 1176)
Impossible de trouver l'extension:
/usr/pkg/scribus135/lib/scribus/plugins//libsubdivide.so: Undefined
symbol "_ZN14ScActionPlugin16staticMetaObjectE" (symnum = 47)
Ces deux symboles sont définis dans le programme principal, mais l'un
est de type « R » et l'autre « V ». J'imagine que cette erreur provient
de dlopen () au chargement des .so.
D'où ma question : comment résoudre ce problème ? En changeant un
paramètre à l'édition de liens (RPATH ?) ou bien en modifiant le code
pour passer les symboles irrésolus en type « T » ou équivalent ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
espie
In article <47ee0a65$0$30443$, Vincent (ex Elendir) wrote:
Impossible de trouver l'extension: /usr/pkg/scribus135/lib/scribus/plugins//libscriptplugin.so: Undefined symbol "_ZTI13UpdateMemento" (symnum = 1176) Impossible de trouver l'extension: /usr/pkg/scribus135/lib/scribus/plugins//libsubdivide.so: Undefined symbol "_ZN14ScActionPlugin16staticMetaObjectE" (symnum = 47)
Ces deux symboles sont définis dans le programme principal, mais l'un est de type « R » et l'autre « V ». J'imagine que cette erreur provient de dlopen () au chargement des .so.
Deux possibilites: soit il y a quelque chose qui deconne sur le name-mangling (tu es bien sur de l'orthographe des symboles, en particulier des soulignes ?), soit c'est un probleme de mode de dlopen... Il y a des flags assez variables selon les systemes qui permettent a un plugin d'avoir (ou non) acces a tous les autres symboles du process en cours. Ce que tu decris (symbole defini dans le programme principal invisible depuis un des plugins) semble correspondre a cela.
Je ne connais pas V, mais ca doit correspondre au controle de visibilite dont les gcc recents sont capables... il est possible que ca deconne sous NetBSD, ca va dependre du linker, et c'est assez recent et un peu exotique comme extension... en desespoir de cause, regarde dans ton log de cmake s'il y a un test pour activer ce support, et desactive-le.
Sans garantie de resultats, mais c'est tout ce que je peux dire ave tes infos.
In article <47ee0a65$0$30443$426a74cc@news.free.fr>,
Vincent (ex Elendir) <10.50@free.fr> wrote:
Impossible de trouver l'extension:
/usr/pkg/scribus135/lib/scribus/plugins//libscriptplugin.so: Undefined
symbol "_ZTI13UpdateMemento" (symnum = 1176)
Impossible de trouver l'extension:
/usr/pkg/scribus135/lib/scribus/plugins//libsubdivide.so: Undefined
symbol "_ZN14ScActionPlugin16staticMetaObjectE" (symnum = 47)
Ces deux symboles sont définis dans le programme principal, mais l'un
est de type « R » et l'autre « V ». J'imagine que cette erreur provient
de dlopen () au chargement des .so.
Deux possibilites: soit il y a quelque chose qui deconne sur le name-mangling
(tu es bien sur de l'orthographe des symboles, en particulier des soulignes ?),
soit c'est un probleme de mode de dlopen... Il y a des flags assez variables
selon les systemes qui permettent a un plugin d'avoir (ou non) acces a
tous les autres symboles du process en cours. Ce que tu decris (symbole
defini dans le programme principal invisible depuis un des plugins) semble
correspondre a cela.
Je ne connais pas V, mais ca doit correspondre au controle de visibilite dont
les gcc recents sont capables... il est possible que ca deconne sous NetBSD,
ca va dependre du linker, et c'est assez recent et un peu exotique comme
extension... en desespoir de cause, regarde dans ton log de cmake s'il y a un
test pour activer ce support, et desactive-le.
Sans garantie de resultats, mais c'est tout ce que je peux dire ave tes infos.
In article <47ee0a65$0$30443$, Vincent (ex Elendir) wrote:
Impossible de trouver l'extension: /usr/pkg/scribus135/lib/scribus/plugins//libscriptplugin.so: Undefined symbol "_ZTI13UpdateMemento" (symnum = 1176) Impossible de trouver l'extension: /usr/pkg/scribus135/lib/scribus/plugins//libsubdivide.so: Undefined symbol "_ZN14ScActionPlugin16staticMetaObjectE" (symnum = 47)
Ces deux symboles sont définis dans le programme principal, mais l'un est de type « R » et l'autre « V ». J'imagine que cette erreur provient de dlopen () au chargement des .so.
Deux possibilites: soit il y a quelque chose qui deconne sur le name-mangling (tu es bien sur de l'orthographe des symboles, en particulier des soulignes ?), soit c'est un probleme de mode de dlopen... Il y a des flags assez variables selon les systemes qui permettent a un plugin d'avoir (ou non) acces a tous les autres symboles du process en cours. Ce que tu decris (symbole defini dans le programme principal invisible depuis un des plugins) semble correspondre a cela.
Je ne connais pas V, mais ca doit correspondre au controle de visibilite dont les gcc recents sont capables... il est possible que ca deconne sous NetBSD, ca va dependre du linker, et c'est assez recent et un peu exotique comme extension... en desespoir de cause, regarde dans ton log de cmake s'il y a un test pour activer ce support, et desactive-le.
Sans garantie de resultats, mais c'est tout ce que je peux dire ave tes infos.
Vincent (ex Elendir)
Re-
Deux possibilites: soit il y a quelque chose qui deconne sur le name-mangling (tu es bien sur de l'orthographe des symboles, en particulier des soulignes ?),
Oui, oui, de ce côté là, je crois que tout est correct.
soit c'est un probleme de mode de dlopen... Il y a des flags assez variables selon les systemes qui permettent a un plugin d'avoir (ou non) acces a tous les autres symboles du process en cours. Ce que tu decris (symbole defini dans le programme principal invisible depuis un des plugins) semble correspondre a cela.
Je ne connais pas V, mais ca doit correspondre au controle de visibilite dont
Effectivement, le premier symbole est défini en __attribute__ (visibility ("default")) je crois. J'ai essayé de virer cette mention, aucun effet. Ce symbole de type V apparaît comme WEAK dans readelf:
Symbol table '.symtab' contains 18824 entries: Num: Value Size Type Bind Vis Ndx Name 11236: 089bc8e0 8 OBJECT WEAK DEFAULT 15 _ZTI13UpdateMemento
L'autre symbole n'apparaît pas dans readelf, mais existe dans nm :
Apparemment, dans le code, il s'agit d'une fonction retournant un pointeur const sur une adresse const (const trucmuche () const), donc le compilateur la traite comme une simple donnée, apparemment (optimisation ? Remplacer un appel à une fonction retournant toujours la même valeur revient à affecter la valeur directement ?)
Euh, si je peux fournir d'autres renseignements, c'est bien volontiers.
Vincent
Re-
Deux possibilites: soit il y a quelque chose qui deconne sur le name-mangling
(tu es bien sur de l'orthographe des symboles, en particulier des soulignes ?),
Oui, oui, de ce côté là, je crois que tout est correct.
soit c'est un probleme de mode de dlopen... Il y a des flags assez variables
selon les systemes qui permettent a un plugin d'avoir (ou non) acces a
tous les autres symboles du process en cours. Ce que tu decris (symbole
defini dans le programme principal invisible depuis un des plugins) semble
correspondre a cela.
Je ne connais pas V, mais ca doit correspondre au controle de visibilite dont
Effectivement, le premier symbole est défini en __attribute__
(visibility ("default")) je crois. J'ai essayé de virer cette mention,
aucun effet. Ce symbole de type V apparaît comme WEAK dans readelf:
Symbol table '.symtab' contains 18824 entries:
Num: Value Size Type Bind Vis Ndx Name
11236: 089bc8e0 8 OBJECT WEAK DEFAULT 15 _ZTI13UpdateMemento
L'autre symbole n'apparaît pas dans readelf, mais existe dans nm :
Apparemment, dans le code, il s'agit d'une fonction retournant un
pointeur const sur une adresse const (const trucmuche () const), donc le
compilateur la traite comme une simple donnée, apparemment (optimisation
? Remplacer un appel à une fonction retournant toujours la même valeur
revient à affecter la valeur directement ?)
Euh, si je peux fournir d'autres renseignements, c'est bien volontiers.
Deux possibilites: soit il y a quelque chose qui deconne sur le name-mangling (tu es bien sur de l'orthographe des symboles, en particulier des soulignes ?),
Oui, oui, de ce côté là, je crois que tout est correct.
soit c'est un probleme de mode de dlopen... Il y a des flags assez variables selon les systemes qui permettent a un plugin d'avoir (ou non) acces a tous les autres symboles du process en cours. Ce que tu decris (symbole defini dans le programme principal invisible depuis un des plugins) semble correspondre a cela.
Je ne connais pas V, mais ca doit correspondre au controle de visibilite dont
Effectivement, le premier symbole est défini en __attribute__ (visibility ("default")) je crois. J'ai essayé de virer cette mention, aucun effet. Ce symbole de type V apparaît comme WEAK dans readelf:
Symbol table '.symtab' contains 18824 entries: Num: Value Size Type Bind Vis Ndx Name 11236: 089bc8e0 8 OBJECT WEAK DEFAULT 15 _ZTI13UpdateMemento
L'autre symbole n'apparaît pas dans readelf, mais existe dans nm :
Apparemment, dans le code, il s'agit d'une fonction retournant un pointeur const sur une adresse const (const trucmuche () const), donc le compilateur la traite comme une simple donnée, apparemment (optimisation ? Remplacer un appel à une fonction retournant toujours la même valeur revient à affecter la valeur directement ?)
Euh, si je peux fournir d'autres renseignements, c'est bien volontiers.
