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 :
../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 :
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
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,
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é...).
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,
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
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,
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é...).
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.
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.
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.
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.
Le Wed, 4 Feb 2015 12:27:55 +0000 (UTC),
Marc Espie <espie@lain.home> é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
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.
