[Résolu] Problème avec les Autotools

Xaviou · Le 11/05/2007, à 17:09

Bonjour à tous.

J'ai fini de développer un petit logiciel sous edgy.
Il utilise les bibliothèques wxWidgets et FMod.

Pour wxWidgets, pas de problèmes.
Par contre, pour FMod, c'est une autre paire de manches.

J'ai téléchargé les sources, compilé, et installé avec le script fourni. Les fichiers "*.so" sont maintenant dans /usr/local/lib et les headers dans /usr/local/include

Le projet se compile très bien avec Code::Blocks (mais pour cela, il a fallu que je lui indique en dur l'emplacement et le nom du fichier ".so" de FMod.
Si je double-clique sur l'exécutable généré de cette façon, tout marche très bien.

J'ai donc eu dans l'idée de re-compiler en utilisant les Autotools.
Comme je n'ai pas trouvé le moyen d'indiquer l'utilisation de la lib FMod (dans le Makefile.am), j'ai d'abord voulu faire comme sous Code::Blocks, c'est à dire, donner le chemin et le nom du fichier ".so" à linker, pour, dans un premier temps, obtenir quelquechose qui marche.
Et ben raté : le prog compile bien, mais impossible de le lancer : j'obtiens une erreur qui me dit :

error while loading shared libraries: libfmodex64.so: 
cannot open shared object file: No such file or directory

Comment se fait-il que je ne rencontre pas le même problème avec l'éxécutable compilé sous Code::Blocks (qui je le répète, linke avec la même lib) ?

Merci d'avance pour vos réponses, et n'hésitez pas à demander s'il vous faut plus d'infos.

Dernière modification par Xaviou (Le 15/05/2007, à 20:35)

Link31 · Le 11/05/2007, à 21:15

LD_LIBRARY_PATH=/usr/local/lib ./prog

Au fait, Fmod çapuecestpaslibre

Xaviou · Le 11/05/2007, à 21:50

Merci... mais ça ne marche toujours pas ... (toujours le même message d'erreur)

link31 a écrit :

Au fait, Fmod çapuecestpaslibre

J'ai utilisé ça parce que c'est le premier truc qui m'est venu à l'esprit, mais sinon, qu'existe-t'il pour lire des morceaux mp3 présents en mémoire (et éventuellement sur le disque dur) ?

Link31 · Le 11/05/2007, à 22:32

Bon, je suis allé un peu vite : de toute évidence la bibliothèque manquante n'est pas dans /usr/local/lib. Je ne peux pas t'aider à la trouver (essaie toujours avec locate), mais dès que tu l'auras retrouvée, il suffira d'indiquer son chemin avec LD_LIBRARY_PATH.

Qu'est-ce qui pourrait lire des mp3 ? FFmpeg, Lame... évidemment c'est assez différent de FMod. Si tu veux quelque chose de libre qui y ressemble, essaie OpenAL. Par contre il faudra convertir tes morceaux en OGG pour les utiliser avec OpenAL.

Dernière modification par Link31 (Le 11/05/2007, à 22:33)

Xaviou · Le 13/05/2007, à 20:09

Bonsoir, et désolé du retard (week end très chargé...)
Je confirme que la bibliothèque se trouve bien dans /usr/local/lib
C'est d'ailleurs le chemin que j'ai indiqué à Code::Blocks pour le link, et tout est Ok dans ce cas.
J'ai donc mis ce chemin dans le Makefile.am mais ça ne suffit apparament pas : le prog est bien compilé sans erreurs, mais impossible de l'éxécuter.
Voici à quoi ressemble le fichier Makefile.am :

bin_PROGRAMS=wxTest1

INCLUDES = \
	$(WX_CXXFLAGS)

wxTest1_LDFLAGS = \
	$(WX_LIBS) -L/usr/local/lib/ -lfmodex64


wxTest1_LDADD =  \
	$(WX_LIBS) -L/usr/local/lib/ -lfmodex64

wxRBPlayer_SOURCES = \
        ...................... Je vous épargne la liste des fichiers sources mais ils sont ici

Link31 · Le 13/05/2007, à 21:06

Si ça compile sans erreur, le problème n'est sûrement pas dans le Makefile...

Qu'est-ce que renvoie :

ldd ton_fichier_exécutable

?

Xaviou · Le 14/05/2007, à 21:19

Qu'est-ce que renvoie :
ldd ton_fichier_exécutable
?

Tout est bon, sauf la lib fmodex

libwx_gtk2u_aui-2.8.so.0 => /usr/lib/libwx_gtk2u_aui-2.8.so.0 (0x00002ad4de2cf000)
libwx_gtk2u_xrc-2.8.so.0 => /usr/lib/libwx_gtk2u_xrc-2.8.so.0 (0x00002ad4de429000)
libwx_gtk2u_qa-2.8.so.0 => /usr/lib/libwx_gtk2u_qa-2.8.so.0 (0x00002ad4de5c7000)
libwx_gtk2u_html-2.8.so.0 => /usr/lib/libwx_gtk2u_html-2.8.so.0 (0x00002ad4de6ec000)
libwx_gtk2u_adv-2.8.so.0 => /usr/lib/libwx_gtk2u_adv-2.8.so.0 (0x00002ad4de8a2000)
libwx_gtk2u_core-2.8.so.0 => /usr/lib/libwx_gtk2u_core-2.8.so.0 (0x00002ad4dea89000)
libwx_baseu_xml-2.8.so.0 => /usr/lib/libwx_baseu_xml-2.8.so.0 (0x00002ad4defba000)
libwx_baseu_net-2.8.so.0 => /usr/lib/libwx_baseu_net-2.8.so.0 (0x00002ad4df0c5000)
libwx_baseu-2.8.so.0 => /usr/lib/libwx_baseu-2.8.so.0 (0x00002ad4df1f6000)
libfmodex64.so => not found
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00002ad4df45c000)
libm.so.6 => /lib/libm.so.6 (0x00002ad4df65c000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002ad4df7dd000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00002ad4df8eb000)
libc.so.6 => /lib/libc.so.6 (0x00002ad4dfa01000)
libz.so.1 => /usr/lib/libz.so.1 (0x00002ad4dfc41000)
libdl.so.2 => /lib/libdl.so.2 (0x00002ad4dfd58000)
libgstreamer-0.10.so.0 => /usr/lib/libgstreamer-0.10.so.0 (0x00002ad4dfe5c000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00002ad4e0004000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x00002ad4e0146000)
libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0x00002ad4e0383000)
libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0x00002ad4e04bf000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00002ad4e062d000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00002ad4e0730000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00002ad4e0834000)
libgstinterfaces-0.10.so.0 => /usr/lib/libgstinterfaces-0.10.so.0 (0x00002ad4e09d3000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00002ad4e0adc000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x00002ad4e0f6f000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x00002ad4e1108000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00002ad4e1228000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00002ad4e1340000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00002ad4e1480000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00002ad4e1591000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00002ad4e169a000)
libXi.so.6 => /usr/lib/libXi.so.6 (0x00002ad4e179d000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00002ad4e18a5000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00002ad4e19a8000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00002ad4e1ab3000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x00002ad4e1bb8000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00002ad4e1cf8000)
libSM.so.6 => /usr/lib/libSM.so.6 (0x00002ad4e1ed8000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00002ad4e1fe2000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00002ad4e2106000)
libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00002ad4e2229000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00002ad4e2383000)
/lib64/ld-linux-x86-64.so.2 (0x00002ad4de1b2000)
librt.so.1 => /lib/librt.so.1 (0x00002ad4e24a6000)
libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00002ad4e25af000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00002ad4e26b9000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00002ad4e2822000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00002ad4e299b000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00002ad4e2a9e000)
libICE.so.6 => /usr/lib/libICE.so.6 (0x00002ad4e2ba4000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x00002ad4e2cbf000)

Link31 · Le 14/05/2007, à 22:29

Bah tout a l'air bon, alors il ne reste qu'une seule explication... la bibliothèque n'est pas utilisable, pour une raison quelconque. Ça peut être parce qu'elle est en 32 bits alors que le programme est en 64 bits ou vice/versa, mais ça paraît assez improbable si tu l'as compilée.

Pour plus d'infos sur cette bibliothèque :

file /usr/local/lib/libfmodex64.so

Essaie de la réinstaller, voire de la recompiler, à tout hasard.

Xaviou · Le 14/05/2007, à 23:34

Ce qui est bizarre, c'est que si je compile mon prog directement avec Code::Blocks (en linkant avec cette lib, bien sûr), et bien tout marche sans problème.
Je n'ai pas compilé la lib : elle est téléchargeable déjà compilée.

Voici le résultat de la commande ldd sur l'éxécutable compilé avec Code::Blocks :

libwx_gtk2u_aui-2.8.so.0 => /usr/lib/libwx_gtk2u_aui-2.8.so.0 (0x00002b7c094e9000)
libwx_gtk2u_xrc-2.8.so.0 => /usr/lib/libwx_gtk2u_xrc-2.8.so.0 (0x00002b7c09643000)
libwx_gtk2u_qa-2.8.so.0 => /usr/lib/libwx_gtk2u_qa-2.8.so.0 (0x00002b7c097e1000)
libwx_gtk2u_html-2.8.so.0 => /usr/lib/libwx_gtk2u_html-2.8.so.0 (0x00002b7c09906000)
libwx_gtk2u_adv-2.8.so.0 => /usr/lib/libwx_gtk2u_adv-2.8.so.0 (0x00002b7c09abc000)
libwx_gtk2u_core-2.8.so.0 => /usr/lib/libwx_gtk2u_core-2.8.so.0 (0x00002b7c09ca3000)
libwx_baseu_xml-2.8.so.0 => /usr/lib/libwx_baseu_xml-2.8.so.0 (0x00002b7c0a1d4000)
libwx_baseu_net-2.8.so.0 => /usr/lib/libwx_baseu_net-2.8.so.0 (0x00002b7c0a2df000)
libwx_baseu-2.8.so.0 => /usr/lib/libwx_baseu-2.8.so.0 (0x00002b7c0a410000)
/usr/local/lib/libfmodex64.so (0x00002b7c0a675000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00002b7c0a94f000)
libm.so.6 => /lib/libm.so.6 (0x00002b7c0ab4f000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002b7c0acd0000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00002b7c0adde000)
libc.so.6 => /lib/libc.so.6 (0x00002b7c0aef4000)
libz.so.1 => /usr/lib/libz.so.1 (0x00002b7c0b134000)
libdl.so.2 => /lib/libdl.so.2 (0x00002b7c0b24b000)
libgstreamer-0.10.so.0 => /usr/lib/libgstreamer-0.10.so.0 (0x00002b7c0b34f000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00002b7c0b4f7000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x00002b7c0b639000)
libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0x00002b7c0b876000)
libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0x00002b7c0b9b2000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00002b7c0bb20000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00002b7c0bc23000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00002b7c0bd27000)
libgstinterfaces-0.10.so.0 => /usr/lib/libgstinterfaces-0.10.so.0 (0x00002b7c0bec6000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00002b7c0bfcf000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x00002b7c0c462000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x00002b7c0c5fb000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00002b7c0c71b000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00002b7c0c833000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00002b7c0c973000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00002b7c0ca84000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00002b7c0cb8d000)
libXi.so.6 => /usr/lib/libXi.so.6 (0x00002b7c0cc90000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00002b7c0cd98000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00002b7c0ce9b000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00002b7c0cfa6000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x00002b7c0d0ab000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00002b7c0d1eb000)
libSM.so.6 => /usr/lib/libSM.so.6 (0x00002b7c0d3cb000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00002b7c0d4d5000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00002b7c0d5f9000)
libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00002b7c0d71c000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00002b7c0d876000)
/lib64/ld-linux-x86-64.so.2 (0x00002b7c093cc000)
librt.so.1 => /lib/librt.so.1 (0x00002b7c0d999000)
libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00002b7c0daa2000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00002b7c0dbac000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00002b7c0dd15000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00002b7c0de8e000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00002b7c0df91000)
libICE.so.6 => /usr/lib/libICE.so.6 (0x00002b7c0e097000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x00002b7c0e1b2000)

et voici le résultat de la commande file sur le fichier lib :

file /usr/local/lib/libfmodex64.so
/usr/local/lib/libfmodex64.so: symbolic link to `/usr/local/lib/libfmodex64.so.4.06.12'
file /usr/local/lib/libfmodex64.so.4.06.12
/usr/local/lib/libfmodex64.so.4.06.12: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped

En tout cas, merci de t'intéresser à mon pb.

Link31 · Le 14/05/2007, à 23:52

Xaviou a écrit :

/usr/local/lib/libfmodex64.so (0x00002b7c0a675000)

Un chemin hardcodé ? Pas terrible... Si c'est tout ce que sait faire Code::Blocks, c'est assez décevant.

Quoi qu'il en soit, on va essayer de faire ça proprement. La commande avec LD_LIBRARY_PATH doit fonctionner, il n'y a aucune raison que ça ne passe pas.
Normalement :

LD_LIBRARY_PATH=/usr/local/lib ldd exécutable

devrait indiquer que la bibliothèque est détectée.

Dans ce cas :

LD_LIBRARY_PATH=/usr/local/lib ./exécutable

fonctionnera.

Je ne vois pas d'autre solution, et je ne vois pas en quoi ça ne passerait pas.

À moins que...

Xaviou a écrit :

file /usr/local/lib/libfmodex64.so.4.06.12
/usr/local/lib/libfmodex64.so.4.06.12: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped

Tu es bien en 64 bits, n'est-ce pas ?

Xaviou · Le 15/05/2007, à 00:14

Link31 a écrit :

Xaviou a écrit :
/usr/local/lib/libfmodex64.so (0x00002b7c0a675000)
Un chemin hardcodé ? Pas terrible... Si c'est tout ce que sait faire Code::Blocks, c'est assez décevant.

Non, je te rassures, mais c'est la seule solution que j'ai trouvé pour cette lib. sinon, pour tout le reste, le nom de la lib suffit (de toute façon, Code::Blocks n'est qu'un IDE, et se sert du ou des compilateurs installé(s) sur le système).

Link31 a écrit :

Quoi qu'il en soit, on va essayer de faire ça proprement. La commande avec LD_LIBRARY_PATH doit fonctionner, il n'y a aucune raison que ça ne passe pas.
Normalement :
LD_LIBRARY_PATH=/usr/local/lib ldd exécutable
devrait indiquer que la bibliothèque est détectée.
Dans ce cas :
LD_LIBRARY_PATH=/usr/local/lib ./exécutable
fonctionnera.
Je ne vois pas d'autre solution, et je ne vois pas en quoi ça ne passerait pas.

Effectivement, ce coup-ci, ça marche. Je ne sais pas ce qui a pu foirer le premier coup.
Toujours est-il que ça n'explique pas le fait que je ne soit pas obligé de faire cela avec l'éxécutable de Code::Blocks (un double-clic depuis le Navigateur de fichiers suffit à lancer le prog).

Link31 a écrit :

À moins que...
Xaviou a écrit :
file /usr/local/lib/libfmodex64.so.4.06.12
/usr/local/lib/libfmodex64.so.4.06.12: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped
Tu es bien en 64 bits, n'est-ce pas ?

Oui, oui, je te rassures.

Link31 · Le 15/05/2007, à 00:26

Xaviou a écrit :

Non, je te rassures, mais c'est la seule solution que j'ai trouvé pour cette lib. sinon, pour tout le reste, le nom de la lib suffit (de toute façon, Code::Blocks n'est qu'un IDE, et se sert du ou des compilateurs installé(s) sur le système).

OK, je croyais que C::B avait fait ça tout seul (par défaut).

Xaviou a écrit :

Effectivement, ce coup-ci, ça marche. Je ne sais pas ce qui a pu foirer le premier coup.
Toujours est-il que ça n'explique pas le fait que je ne soit pas obligé de faire cela avec l'éxécutable de Code::Blocks (un double-clic depuis le Navigateur de fichiers suffit à lancer le prog).

Si, ça s'explique très facilement. Le chemin de la bibliothèque étant hardcodé dans l'exécutable de C::B, le système la trouve sans problèmes. Mais si tu transmets l'exécutable à quelqu'un d'autre, ça ne fonctionnera pas forcément, car la bibliothèque ne sera pas forcément exactement au même endroit. C'est pourquoi hardcoder le chemin d'une bibliothèque est absolument à éviter.

La variable d'environnement LD_LIBRARY_PATH sert à indiquer au système où chercher les bibliothèques. La recherche se fait systématiquement dans /lib et /usr/lib (dans ce cas pas besoin de LD_LIBRARY_PATH ), mais selon les distributions, elle ne se fait pas toujours dans /usr/local/lib.
La solution serait d'installer la bibliothèque dans /usr/lib (voir l'option --prefix lors du ./configure). Mais en général on préfère laisser la partie /usr à apt-get, et installer tout ce qui ne passe pas par apt-get dans /usr/local. À toi de voir.

Xaviou · Le 15/05/2007, à 07:31

Link31 a écrit :

Xaviou a écrit :
Xaviou a écrit :
Effectivement, ce coup-ci, ça marche. Je ne sais pas ce qui a pu foirer le premier coup.
Toujours est-il que ça n'explique pas le fait que je ne soit pas obligé de faire cela avec l'éxécutable de Code::Blocks (un double-clic depuis le Navigateur de fichiers suffit à lancer le prog).
Si, ça s'explique très facilement. Le chemin de la bibliothèque étant hardcodé dans l'exécutable de C::B, le système la trouve sans problèmes. Mais si tu transmets l'exécutable à quelqu'un d'autre, ça ne fonctionnera pas forcément, car la bibliothèque ne sera pas forcément exactement au même endroit. C'est pourquoi hardcoder le chemin d'une bibliothèque est absolument à éviter.

Il me semble bien avoir fait l'essai en indiquant le chemin "en dur" dans le Makefile.am. Je re-ferais l'essai ce soir pour vérifier.

Link31 a écrit :

La variable d'environnement LD_LIBRARY_PATH sert à indiquer au système où chercher les bibliothèques. La recherche se fait systématiquement dans /lib et /usr/lib (dans ce cas pas besoin de LD_LIBRARY_PATH ), mais selon les distributions, elle ne se fait pas toujours dans /usr/local/lib.
La solution serait d'installer la bibliothèque dans /usr/lib (voir l'option --prefix lors du ./configure). Mais en général on préfère laisser la partie /usr à apt-get, et installer tout ce qui ne passe pas par apt-get dans /usr/local. À toi de voir.

Le problème c'est que FMod n'est pas livré sous forme de paquet source à compiler (donc pas de --prefix possible), mais sous forme de lib à installer directement (avec un Makefile pour l'installation qui copie les libs dans /usr/local/lib).
Le solution serait de fournir les libs dans le paquet final, et de les installer correctement lors du make install, mais vu la licence, j'ai des doutes sur la légalité d'une telle action.
Tant pis, il va falloir que je jette un coup d'oeil du côté des autres libs.

Merci quand même... (je passerais le topic en résolu ce soir après avoir fait les derniers test...)

Xaviou · Le 15/05/2007, à 17:52

Y'a rien à faire, ça ne veux pas marcher :

wxTest1_LDFLAGS = \
    $(WX_LIBS) -L/usr/local/lib/ -lfmodex64

wxTest1_LDADD =  \
    $(WX_LIBS) -L/usr/local/lib/ -lfmodex64

En ne mettant pas le chemin de la lib "en dur", ça compile, mais impossible de l'éxécuter

wxTest1_LDFLAGS = \
    $(WX_LIBS) -L/usr/local/lib/ -l/usr/local/lib/fmodex64

wxTest1_LDADD =  \
    $(WX_LIBS) -L/usr/local/lib/ -l/usr/local/lib/fmodex64

En le mettant comme ça, ça ne veut pas compiler : /usr/bin/ld: ne peut trouver -l/usr/local/lib/fmodex64

De même, si je mets -l/usr/local/lib/libfmodex64.so, il ne veut pas compiler.

Décidément, c'est vraiment bizarre

Link31 · Le 15/05/2007, à 19:46

Il faut aussi utiliser la variable LD_LIBRARY_PATH lors de la compilation. Avec elle, plus besoin de spécifier les chemins en dur, le paramètre -lfmodx64 fonctionnera.

Tu peux aussi l'exporter dans le shell (export LD_LIBRARY_PATH=/usr/local/lib) pour qu'elle fasse effet pendant toute la session de ce même shell.

Si tu en as marre de taper ça à chaque fois, essaie d'installer la bibliothèque à un endroit plus standard (/usr/lib).

Xaviou · Le 15/05/2007, à 20:34

Effectivement, en installant la bibliothèque dans /usr/lib, tout marche impec.

Faut que je regarde s'il est possible de fournir le fichier lib dans le paquet, et sinon, dans le pire des cas, ajouter une instruction pour l'installation des libs avant la compilation.

En tout cas, un grand merci pour ton aide....

lordphoenix · Le 17/05/2007, à 11:14

Vu que vous avez l'air de connaitre les autotools je me permet de squatter le sujet pour vous demander si vous ne connaitriez pas des endroits ou je peux trouver de la doc dessus de préférence en français.
Je voudrais les utiliser pour des projets Mono/C# car j'en ai marre de la lourdeur de monodevelop.

Merci d'avance.

Xaviou · Le 17/05/2007, à 16:17

Salut.

Tu peux déjà jeter un coup d'oeil à ce pdf (français).

Sinon, il y a ce tuto qui n'est pas mal non plus (mais en anglais).

Bonne lecture

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 11/05/2007, à 17:09

[Résolu] Problème avec les Autotools

#2 Le 11/05/2007, à 21:15

Re : [Résolu] Problème avec les Autotools

#3 Le 11/05/2007, à 21:50

Re : [Résolu] Problème avec les Autotools

#4 Le 11/05/2007, à 22:32

Re : [Résolu] Problème avec les Autotools

#5 Le 13/05/2007, à 20:09

Re : [Résolu] Problème avec les Autotools

#6 Le 13/05/2007, à 21:06

Re : [Résolu] Problème avec les Autotools

#7 Le 14/05/2007, à 21:19

Re : [Résolu] Problème avec les Autotools

#8 Le 14/05/2007, à 22:29

Re : [Résolu] Problème avec les Autotools

#9 Le 14/05/2007, à 23:34

Re : [Résolu] Problème avec les Autotools

#10 Le 14/05/2007, à 23:52

Re : [Résolu] Problème avec les Autotools

#11 Le 15/05/2007, à 00:14

Re : [Résolu] Problème avec les Autotools

#12 Le 15/05/2007, à 00:26

Re : [Résolu] Problème avec les Autotools

#13 Le 15/05/2007, à 07:31

Re : [Résolu] Problème avec les Autotools

#14 Le 15/05/2007, à 17:52

Re : [Résolu] Problème avec les Autotools

#15 Le 15/05/2007, à 19:46

Re : [Résolu] Problème avec les Autotools

#16 Le 15/05/2007, à 20:34

Re : [Résolu] Problème avec les Autotools

#17 Le 17/05/2007, à 11:14

Re : [Résolu] Problème avec les Autotools

#18 Le 17/05/2007, à 16:17

Re : [Résolu] Problème avec les Autotools

Pied de page des forums