Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS BSD Problème d'édition des liens (C++)

Problème d'édition des liens (C++)

3 réponses
Avatar
JKB
Bonjour à tous,

Mon épouse utilise un outil assez ancien et plus supporté qui
s'appelle knoda. J'ai réussi à le recompiler sur son netbook
(debian/amd64 jessie). Pour cela, j'ai dû recompiler :
- qt-x11-free-3.3.8b (en patchant les sources) ;
- kdelibs-3.5.10 ;
- hk_classes-0.8.3 ;
- knoda-0.8.3.

Ça fonctionne. Seulement, elle vient de s'enfermer à la campagne
pour terminer ses travaux et , plutôt que de bosser sur un petit
netbook très pratique pour aller aux archives nationales et à la
BNF, sa machine de travail est un gros portable 17" muni d'un
Pentium 4 qui a trouvé une nouvelle jeunesse avec un FreeBSD des
familles (un 10.1 à jour de ce matin).

Sur ce FreeBSD, je n'arrive pas à compiler knoda. J'ai bien réussi à
compiler les prérequis, mais l'édition des liens de knoda (la
dernière, la finale...) se vautre lamentablement avec les erreurs
suivantes :

gmake[3] : on entre dans le répertoire
« /.amd_mnt/192.168.0.128/host/export/home/bertrand/knoda-0.8.3/knoda »
/bin/sh ../libtool --silent --tag=CXX --mode=link g++ -Wno-long-long
-Wundef -Wall -W -Wpointer-arith -O2 -g -O2 -Wno-non-virtual-dtor
-fno-exceptions -fno-check-new -fno-common -R /opt/lib -R /opt/lib -R
/opt/lib -R /usr/lib -L/opt/lib -L/usr/lib -o knoda main.o
knodanewdatabasedialog.o knodaprogram.o knodaprogrambase.o knodawin.o
knodawinbase.o hk_kdedriverselectbase.o hk_kdedriverselect.o -lkmdi
../hk_kdeclasses/libhk_kdeclasses.la -lkparts -L/usr/local/lib -lxml2
-lz -L/usr/lib -lm -L/opt/lib/hk_classes/ -lhk_classes

../hk_kdeclasses/.libs/libhk_kdeclasses.a(hk_kdedblistview.o): In
function `hk_kdeschemadialog::hk_kdeschemadialog(QWidget*, char const*,
bool, unsigned int)':
/export/home/bertrand/knoda-0.8.3/hk_kdeclasses/hk_kdedblistview.cpp:101:
multiple definition of `hk_kdeschemadialog::hk_kdeschemadialog(QWidget*,
char const*, bool, unsigned int)'
knodawinbase.o:/export/home/bertrand/knoda-0.8.3/knoda/knodawinbase.cpp:73:
first defined here
../hk_kdeclasses/.libs/libhk_kdeclasses.a(hk_kdedblistview.o): In
function `hk_kdeschemadialog::hk_kdeschemadialog(QWidget*, char const*,
bool, unsigned int)':
/export/home/bertrand/knoda-0.8.3/hk_kdeclasses/hk_kdedblistview.cpp:101:
multiple definition of `hk_kdeschemadialog::hk_kdeschemadialog(QWidget*,
char const*, bool, unsigned int)'
knodawinbase.o:/export/home/bertrand/knoda-0.8.3/knoda/knodawinbase.cpp:73:
first defined here
../hk_kdeclasses/.libs/libhk_kdeclasses.a(hk_kdedblistview.o): In
function `hk_kdeschemadialog::~hk_kdeschemadialog()':
/export/home/bertrand/knoda-0.8.3/hk_kdeclasses/hk_kdedblistview.cpp:150:
multiple definition of `hk_kdeschemadialog::~hk_kdeschemadialog()'
knodawinbase.o:/export/home/bertrand/knoda-0.8.3/knoda/knodawinbase.cpp:125:
first defined here
../hk_kdeclasses/.libs/libhk_kdeclasses.a(hk_kdedblistview.o): In
function `hk_kdeschemadialog::~hk_kdeschemadialog()':
/export/home/bertrand/knoda-0.8.3/hk_kdeclasses/hk_kdedblistview.cpp:150:
multiple definition of `hk_kdeschemadialog::~hk_kdeschemadialog()'
knodawinbase.o:/export/home/bertrand/knoda-0.8.3/knoda/knodawinbase.cpp:125:
first defined here
../hk_kdeclasses/.libs/libhk_kdeclasses.a(hk_kdedblistview.o): In
function `__static_initialization_and_destruction_0':
/export/home/bertrand/knoda-0.8.3/hk_kdeclasses/hk_kdedblistview.h:192:
multiple definition of `non-virtual thunk to
hk_kdeschemadialog::~hk_kdeschemadialog()'
knodawinbase.o:/export/home/bertrand/knoda-0.8.3/knoda/knodawinbase.h:222:
first defined here
../hk_kdeclasses/.libs/libhk_kdeclasses.a(hk_kdedblistview.o): In
function `hk_kdeschemadialog::~hk_kdeschemadialog()':
/export/home/bertrand/knoda-0.8.3/hk_kdeclasses/hk_kdedblistview.cpp:150:
multiple definition of `hk_kdeschemadialog::~hk_kdeschemadialog()'
knodawinbase.o:/export/home/bertrand/knoda-0.8.3/knoda/knodawinbase.cpp:125:
first defined here
../hk_kdeclasses/.libs/libhk_kdeclasses.a(hk_kdedblistview.o): In
function `__static_initialization_and_destruction_0':
/export/home/bertrand/knoda-0.8.3/hk_kdeclasses/hk_kdedblistview.h:192:
multiple definition of `non-virtual thunk to
hk_kdeschemadialog::~hk_kdeschemadialog()'
knodawinbase.o:/export/home/bertrand/knoda-0.8.3/knoda/knodawinbase.h:222:
first defined here
../hk_kdeclasses/.libs/libhk_kdeclasses.a(hk_kdecsvexportdialog.o): In
function `hk_kdecsvexportdialog::staticMetaObject()':
/export/home/bertrand/knoda-0.8.3/hk_kdeclasses/hk_kdecsvexportdialog.moc:54:
undefined reference to `hk_kdecsvexportdialogbase::staticMetaObject()'
../hk_kdeclasses/.libs/libhk_kdeclasses.a(hk_kdecsvexportdialog.o): In
function `hk_kdecsvexportdialog::qt_cast(char const*)':
/export/home/bertrand/knoda-0.8.3/hk_kdeclasses/hk_kdecsvexportdialog.moc:90:
undefined reference to `hk_kdecsvexportdialogbase::qt_cast(char const*)'
../hk_kdeclasses/.libs/libhk_kdeclasses.a(hk_kdecsvexportdialog.o): In
function `hk_kdecsvexportdialog::qt_invoke(int, QUObject*)':
/export/home/bertrand/knoda-0.8.3/hk_kdeclasses/hk_kdecsvexportdialog.moc:104:
undefined reference to `hk_kdecsvexportdialogbase::qt_invoke(int,
QUObject*)'
../hk_kdeclasses/.libs/libhk_kdeclasses.a(hk_kdecsvexportdialog.o): In
function `hk_kdecsvexportdialog::qt_emit(int, QUObject*)':
/export/home/bertrand/knoda-0.8.3/hk_kdeclasses/hk_kdecsvexportdialog.moc:111:
undefined reference to `hk_kdecsvexportdialogbase::qt_emit(int,
QUObject*)'
../hk_kdeclasses/.libs/libhk_kdeclasses.a(hk_kdecsvexportdialog.o): In
function `hk_kdecsvexportdialog::qt_property(int, int, QVariant*)':
/export/home/bertrand/knoda-0.8.3/hk_kdeclasses/hk_kdecsvexportdialog.moc:117:
undefined reference to `hk_kdecsvexportdialogbase::qt_property(int, int,
QVariant*)'
...

Dans le passé, j'avais déjà compilé avec succès cette application
sous FreeBSD 7 puis 8.

Toutes les bibliothèques sont dans /opt/lib. Elles semblent toutes
fonctionnelles. J'avoue ne plus trop savoir où chercher... Dois-je
mettre en cause g++, le linker, l'OS ? L'ordre d'édition des liens ?
J'ai essayé ceci :

pythagore:[~/knoda-0.8.3/knoda] > /bin/sh ../libtool --silent --tag=CXX
--mode=link g++ -Wno-long-long -Wundef -Wall -W -Wpointer-arith -O2 -g
-O2 -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -R
/opt/lib -R /usr/lib -o knoda main.o knodanewdatabasedialog.o
knodaprogram.o knodaprogrambase.o knodawin.o knodawinbase.o
hk_kdedriverselectbase.o hk_kdedriverselect.o -lkmdi
/opt/lib/hk_classes/libhk_classes.la -lkparts -L/usr/local/lib
-L/opt/lib -L/opt/lib/hk_classes/ -lkparts -lhk_classes -L/usr/lib
-lxml2 -lz -lm -liconv

qui donne d'autres erreurs du même tonneau. J'avoue que je commence
à désespérer.

Merci de vos éventuelles lumières,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Signaler un problème avec ce contenu

3 réponses

Supprimer
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
Avatar
JKB
Le Tue, 3 Feb 2015 10:44:06 +0000 (UTC),
JKB écrivait :
gmake[3] : on entre dans le répertoire
« /.amd_mnt/192.168.0.128/host/export/home/bertrand/knoda-0.8.3/knoda »
/bin/sh ../libtool --silent --tag=CXX --mode=link g++ -Wno-long-long
-Wundef -Wall -W -Wpointer-arith -O2 -g -O2 -Wno-non-virtual-dtor
-fno-exceptions -fno-check-new -fno-common -R /opt/lib -R /opt/lib -R
/opt/lib -R /usr/lib -L/opt/lib -L/usr/lib -o knoda main.o
knodanewdatabasedialog.o knodaprogram.o knodaprogrambase.o knodawin.o
knodawinbase.o hk_kdedriverselectbase.o hk_kdedriverselect.o -lkmdi
../hk_kdeclasses/libhk_kdeclasses.la -lkparts -L/usr/local/lib -lxml2
-lz -L/usr/lib -lm -L/opt/lib/hk_classes/ -lhk_classes



Je viens de trouver une partie du problème. Les scripts de
compilation effectuent un test sur freebsd1* pour éviter la
construction des bibliothèques partagées, ce qui fait que
l'exécutable final est lié avec une moitié de bibliothèques
statiques et une autre de dynamiques, ce qui semble lui poser un
problème d'ordre à l'édition des liens, ordre que je n'arrive pas à
corriger.

J'ai donc modifié tous les scripts de compilation de la libkde pour
remplacer les tests freebsd1*) par freebsd1.*). Là, le système veut
bien tenter de compiler des bibliothèques dynamiques (dixit
configure) mais libtool se bauge un peu plus loin. En effet,

/bin/sh ../libtool --silent --tag=CXX --mode=link g++
-DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT
-DQT_NO_TRANSLATION -R /opt/lib -R /opt/lib -R /opt/lib -version-info
6:0:2 -no-undefined -L/opt/lib -L/opt/lib -o libDCOP.la -rpath /opt/lib
dcopstub.lo dcopref.lo dcopobject.lo dcopclient.lo KDE-ICE/libkICE.la
-lqt-mt -lz -lpng -lz -lm -lXext -lX11 -lSM -lICE -lpthread

qui exécute effectivement :

ar cru .libs/libDCOP.a dcopstub.o dcopref.o dcopobject.o dcopclient.o
.libs/libDCOP.lax/libkICE.a/accept.o
.libs/libDCOP.lax/libkICE.a/authutil.o
.libs/libDCOP.lax/libkICE.a/connect.o
.libs/libDCOP.lax/libkICE.a/error.o
.libs/libDCOP.lax/libkICE.a/getauth.o
.libs/libDCOP.lax/libkICE.a/iceauth.o
.libs/libDCOP.lax/libkICE.a/listen.o
.libs/libDCOP.lax/libkICE.a/listenwk.o
.libs/libDCOP.lax/libkICE.a/locking.o .libs/libDCOP.lax/libkICE.a/misc.o
.libs/libDCOP.lax/libkICE.a/ping.o .libs/libDCOP.lax/libkICE.a/process.o
.libs/libDCOP.lax/libkICE.a/protosetup.o
.libs/libDCOP.lax/libkICE.a/register.o
.libs/libDCOP.lax/libkICE.a/replywait.o
.libs/libDCOP.lax/libkICE.a/setauth.o
.libs/libDCOP.lax/libkICE.a/shutdown.o
.libs/libDCOP.lax/libkICE.a/watch.o
.libs/libDCOP.lax/libkICE.a/transport.o
.libs/libDCOP.lax/libkICE.a/globals.o
ranlib .libs/libDCOP.a
rm -fr .libs/libDCOP.lax .libs/libDCOP.lax
creating libDCOP.la
(cd .libs && rm -f libDCOP.la && ln -s ../libDCOP.la libDCOP.la)

ne crée pas une bibliothque partagée, mais une statique, ce qui fait
que la ligne suivante :

/bin/sh ../libtool --silent --tag=CXX --mode=link g++
-DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT
-DQT_NO_TRANSLATION -o dcopserver -R /opt/lib -R /opt/lib -R
/opt/lib -no-undefined -L/opt/lib -L/opt/lib dcopserver.la.o
libkdeinit_dcopserver.la

râle très fort avec :

g++: error: ./.libs/libkdeinit_dcopserver.so.0.0: No such file or directory
g++: error: /.amd_mnt/192.168.0.128/host/export/home/bertrand/kdelibs-3.5.10/dcop/.libs/libDCOP.so.6.0: No such file or directory

J'avoue ne pas comprendre pourquoi libtool ne généère par une
bibliotheque dynamique. J'ai bien tenté de forcer du -fPIC à la
compilation, rien n'y fait.

Je tente la compilation sur le NetBSD/sparc64 qui me sert de
serveur, mais j'aimerais tout de même pouvoir le faire tourner sur
une machine un peu plus véloce (et pas avec un affichage X
déporté...).

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Avatar
espie
libtool est une sombre merde. Heureusement, kde s'en est debarrasse pour
kde4.

Si on est encore coince avec, generalement, lorsqu'il refuse de faire de
la bibliotheque dynamique, c'est parce qu'il a trouve un element qu'il veut
linker qui n'existe que en statique.

- cette sombre merde va regarder comment marche gcc, mais n'a jamais
vraiment compris les trucs un peu esoterique a la multi-lib... donc
souvent, il va regarder les bouts internes a la crt0.o, mais ne pas savoir
quoi en foutre, ou juste trouve un libgcc.a, ou un libsupc++.a
et ne pas se rendre compte que c'est compile juste en pic, donc parfaitement
acceptable pour un resultat "shared object".

- souvent, il faut donc aller regarder dans les .la, pour voir dans l'edition
de liens le bout qui fait chier... tu vas pouvoir, au choix, special-caser
dans libtool, inventer une version .so, etc.


Bonne chance.
C'est pas totalement par hasard si on a decide de faire notre propre libtool
dans OpenBSD, apres en avoir horriblement de cet invraisemblable script de
3000 lignes de bon qui ne fait jamais rien convenablement.
Avatar
JKB
Le Wed, 4 Feb 2015 12:27:55 +0000 (UTC),
Marc Espie écrivait :
libtool est une sombre merde. Heureusement, kde s'en est debarrasse pour
kde4.



Je suis contraint à recompiler un kde3...

Si on est encore coince avec, generalement, lorsqu'il refuse de faire de
la bibliotheque dynamique, c'est parce qu'il a trouve un element qu'il veut
linker qui n'existe que en statique.

- cette sombre merde va regarder comment marche gcc, mais n'a jamais
vraiment compris les trucs un peu esoterique a la multi-lib... donc
souvent, il va regarder les bouts internes a la crt0.o, mais ne pas savoir
quoi en foutre, ou juste trouve un libgcc.a, ou un libsupc++.a
et ne pas se rendre compte que c'est compile juste en pic, donc parfaitement
acceptable pour un resultat "shared object".



Merci pour ta réponse. Je suis parfaitement d'accord sur le côté
sombre merde de libtool. Tous les prérequis sont en .so _et_ en .a,
donc je ne vois pas ce qui l'empêche de compiler un .so. Je vais
peut-être essayer de forcer l'édition des liens à la main dès que
j'aurai un peu de temps.

- souvent, il faut donc aller regarder dans les .la, pour voir dans l'edition
de liens le bout qui fait chier... tu vas pouvoir, au choix, special-caser
dans libtool, inventer une version .so, etc.


Bonne chance.
C'est pas totalement par hasard si on a decide de faire notre propre libtool
dans OpenBSD, apres en avoir horriblement de cet invraisemblable script de
3000 lignes de bon qui ne fait jamais rien convenablement.



Merci. Dans l'immédiat, je compile la chose sur NetBSD. Ça semble
passer (et ne pas nécessiter de patches pour compiler kde). C'est
mieux que rien et certainement plus rapide que de trouver pourquoi
libtool se bauge.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr