probleme autoconf automake

Le
Heyberger Ludovic
=_Part_86870_1039260.1175434573944
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Bonjour a tous,

j'aimerait utiliser (ou plutot je suis oblige d'utiliser) les autotools pour
compiler et distribuer un programme de type serveur modulaire et je
rencontre pas mal de problemes depuis le debut.

mon architecture de repertoire est la suivante:

./src
./src/core --> contient main.cpp
./src/core/rep1 --> contient des .cpp utiles a la compilation du serveur
./src/core/rep2 --> idem
./src/core/repn --> idem

donc j'ai suivi les indications de divers tutos expliquants que pour
compiler, je devais passer par autant de libs statiques que de sous
repertoires necessaires a ma compile. j'ai donc les fichiers suivants:

./src/core/rep1/librep1.a
./src/core/rep2/librep2.a
./src/core/repn/librepn.a

que je link ensuite a mon main.o grace a la macro LDADD

la petite feinte dans tout cela, viens du fait que mon serveur doit linker
avec : -Wl,--export-dynamic (pour que les modules puissent acceder aux
fonctions et classes du serveur).

Question 1) : lorsque je lance mon serveur, il essaye de loader les
differents modules, et avec la nouvelle architecture (autotools - avant
j'etait avec un makefile a la main qui faisait un seul link d'un coup), il
me dit que certains symbols sont introuvables (synonyme de mauvais
export-dynamic cote serveur). je n'arrive pas a comprendre, ni a trouver sur
le net une maniere qui me permette de bien compiler mon serveur. qq'un
pourrait-il me donner un coup de main?

Question 2) : mes modules doivent etre compiles en .so. ils se trouvent dans
un sous repertoire de src possedant l'architecture suivante:
./src/modules/mod1/ --> .cpp et .h du module1
./src/modules/mod2/ --> idem
./src/modules/modn/ --> idem

comment faire pour les compiler proprement ? (en .so). certains disent qu'il
faut du libtool, d'autres semblent partis pour faire du automake aussi,
bref je suis un peu perdu. un petit coup de main serait le bienvenue :)


Merci d'avance, bonne journee a tous.

--
105 116 039 115 032 110 111 116 032 097
032 098 117 103 044 032 105 116 039 115
032 097 032 102 101 097 116 117 114 101

=_Part_86870_1039260.1175434573944
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Bonjour a tous,<br><br>j&#39;aimerait utiliser (ou plutot je suis oblige d&#39;utiliser) les autotools pour compiler et distribuer un programme de type serveur modulaire et je rencontre pas mal de problemes depuis le debut.
<br><br>mon architecture de repertoire est la suivante:<br><br>./src<br>./src/core --&gt; contient main.cpp<br>./src/core/rep1 --&gt; contient des .cpp utiles a la compilation du serveur<br>./src/core/rep2 --&gt; idem<br>
./src/core/repn --&gt; idem<br><br>donc j&#39;ai suivi les indications de divers tutos expliquants que pour compiler, je devais passer par autant de libs statiques que de sous repertoires necessaires a ma compile. j&#39;ai donc les fichiers suivants:
<br><br>./src/core/rep1/librep1.a<br>./src/core/rep2/librep2.a<br>./src/core/repn/librepn.a<br><br>que je link ensuite a mon main.o grace a la macro LDADD<br><br>la petite feinte dans tout cela, viens du fait que mon serveur doit linker avec : -Wl,--export-dynamic (pour que les modules puissent acceder aux fonctions et classes du serveur).
<br><br>Question 1) : lorsque je lance mon serveur, il essaye de loader les differents modules, et avec la nouvelle architecture (autotools - avant j&#39;etait avec un makefile a la main qui faisait un seul link d&#39;un coup), il me dit que certains symbols sont introuvables (synonyme de mauvais export-dynamic cote serveur). je n&#39;arrive pas a comprendre, ni a trouver sur le net une maniere qui me permette de bien compiler mon serveur. qq&#39;un pourrait-il me donner un coup de main?
<br><br>Question 2) : mes modules doivent etre compiles en .so. ils se trouvent dans un sous repertoire de src possedant l&#39;architecture suivante:<br>./src/modules/mod1/ --&gt; .cpp et .h du module1<br>./src/modules/mod2/ --&gt; idem
<br>./src/modules/modn/ --&gt; idem<br><br>comment faire pour les compiler proprement ? (en .so). certains disent qu&#39;il faut du libtool, d&#39;autres semblent partis pour faire du automake aussi, &nbsp; bref je suis un peu perdu. un petit coup de main serait le bienvenue :)
<br><br><br>Merci d&#39;avance, bonne journee a tous.<br clear="all"><br>-- <br>105 116 039 115 032 110 111 116 032 097<br>032 098 117 103 044 032 105 116 039 115<br>032 097 032 102 101 097 116 117 114 101

=_Part_86870_1039260.1175434573944--


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Cédric Lucantis
Le #9537421
Le dimanche 1 avril 2007 15:36, Heyberger Ludovic a écrit :

donc j'ai suivi les indications de divers tutos expliquants que pour
compiler, je devais passer par autant de libs statiques que de sous
repertoires necessaires a ma compile. j'ai donc les fichiers suivants:




pas obligé d'utiliser des libs statiques, LTLIBRARIES marche aussi

...

que je link ensuite a mon main.o grace a la macro LDADD



je crois que c'est plutôt LIBADD ici


comment faire pour les compiler proprement ? (en .so). certains disent
qu'il faut du libtool, d'autres semblent partis pour faire du automake
aussi, ... bref je suis un peu perdu. un petit coup de main serait le
bienvenue :)





tu peux laisser automake et libtool faire tout ça, ils se débrouillent bien.
La doc la dessus est éparpillée entre les pages infos automake et libto ol.
L'idée de base, c'est de remplacer tes xx_LIBRARIES par xx_LTLIBRARIES et
d'utiliser l'extension .la au lieu de .a. Automake va ensuite créer des
librairies statiques ou dynamiques (ou les deux) selon ce que veut
l'utilisateur et ce qui est possible.

a part ça, il y'a une liste pour automake :)
http://lists.gnu.org/mailman/listinfo/automake

--
Cédric Lucantis
Cédric Lucantis
Le #9537351
Le dimanche 1 avril 2007 15:36, Heyberger Ludovic a écrit :
Bonjour a tous,

j'aimerait utiliser (ou plutot je suis oblige d'utiliser) les autotools
pour compiler et distribuer un programme de type serveur modulaire et je
rencontre pas mal de problemes depuis le debut.

mon architecture de repertoire est la suivante:

...

donc j'ai suivi les indications de divers tutos expliquants que pour
compiler, je devais passer par autant de libs statiques que de sous
repertoires necessaires a ma compile. j'ai donc les fichiers suivants:

...

que je link ensuite a mon main.o grace a la macro LDADD



C'est plutôt LIBADD dans ce cas je crois, et tu peux utiliser des librair ies
dynamiques.


Question 2) : mes modules doivent etre compiles en .so. ils se trouvent
dans un sous repertoire de src possedant l'architecture suivante:
./src/modules/mod1/ --> .cpp et .h du module1
./src/modules/mod2/ --> idem
./src/modules/modn/ --> idem

comment faire pour les compiler proprement ? (en .so). certains disent
qu'il faut du libtool, d'autres semblent partis pour faire du automake
aussi, ... bref je suis un peu perdu. un petit coup de main serait le
bienvenue :)




Automake/libtool gérent tout ça très bien, mais c'est pas évident à utiliser.
La doc est éparpillée entre les pages info automake et libtool. L'idé e de
base, c'est de remplacer tes xxx_LIBRARIES par xx_LTLIBRARIES et
l'extension .a par .la. Il va alors automatiquement créer des librairies
statiques et/ou dynamiques selon ce que veut l'utilisateur et ce qui est
possible sur la plate-forme.

libtool offre aussi un mécanisme pour gérer les modules externes et plu gins de
façon portable : libltdl (voir info libtool). Ca a l'air d'être ce que tu
cherches...

--
Cédric Lucantis
De Leeuw Guy
Le #9537221
Sinon essaye CMake ?
Guy


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Heyberger Ludovic
Le #9536991
------=_Part_95199_30381311.1175501581738
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Merci pour la reponse, je ne pourrais tester que demain, donc je vous ferai s
un point sur l'avancement a ce moment la!

On 4/1/07, Cédric Lucantis

Le dimanche 1 avril 2007 15:36, Heyberger Ludovic a écrit:
> Bonjour a tous,
>
> j'aimerait utiliser (ou plutot je suis oblige d'utiliser) les autotools
> pour compiler et distribuer un programme de type serveur modulaire et j e
> rencontre pas mal de problemes depuis le debut.
>
> mon architecture de repertoire est la suivante:
>
> ...
>
> donc j'ai suivi les indications de divers tutos expliquants que pour
> compiler, je devais passer par autant de libs statiques que de sous
> repertoires necessaires a ma compile. j'ai donc les fichiers suivants:
>
> ...
>
> que je link ensuite a mon main.o grace a la macro LDADD

C'est plutôt LIBADD dans ce cas je crois, et tu peux utiliser des
librairies
dynamiques.

>
> Question 2) : mes modules doivent etre compiles en .so. ils se trouvent
> dans un sous repertoire de src possedant l'architecture suivante:
> ./src/modules/mod1/ --> .cpp et .h du module1
> ./src/modules/mod2/ --> idem
> ./src/modules/modn/ --> idem
>
> comment faire pour les compiler proprement ? (en .so). certains disent
> qu'il faut du libtool, d'autres semblent partis pour faire du automake
> aussi, ... bref je suis un peu perdu. un petit coup de main serait le
> bienvenue :)
>

Automake/libtool gérent tout ça très bien, mais c'est pas évident à
utiliser.
La doc est éparpillée entre les pages info automake et libtool. L'id ée de
base, c'est de remplacer tes xxx_LIBRARIES par xx_LTLIBRARIES et
l'extension .a par .la. Il va alors automatiquement créer des librairie s
statiques et/ou dynamiques selon ce que veut l'utilisateur et ce qui est
possible sur la plate-forme.

libtool offre aussi un mécanisme pour gérer les modules externes et
plugins de
façon portable : libltdl (voir info libtool). Ca a l'air d'être ce qu e tu
cherches...

--
Cédric Lucantis






--
105 116 039 115 032 110 111 116 032 097
032 098 117 103 044 032 105 116 039 115
032 097 032 102 101 097 116 117 114 101

------=_Part_95199_30381311.1175501581738
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Merci pour la reponse, je ne pourrais tester que demain, donc je vous ferai s un point sur l&#39;avancement a ce moment la!<br><br><div><span class=" gmail_quote">On 4/1/07, <b class="gmail_sendername">Cédric Lucantis</b> &lt;
<br>&gt; Bonjour a tous,<br>&gt;<br>&gt; j&#39;aimerait utiliser (ou plutot je suis oblige d&#39;utiliser) les autotools<br>&gt; pour compiler et dist ribuer un programme de type serveur modulaire et je<br>&gt; rencontre pas m al de problemes depuis le debut.
<br>--<br>Cédric Lucantis<br><br></blockquote></div><br><br clear="all" ><br>-- <br>105 116 039 115 032 110 111 116 032 097<br>032 098 117 103 044 032 105 116 039 115<br>032 097 032 102 101 097 116 117 114 101

------=_Part_95199_30381311.1175501581738--


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Heyberger Ludovic
Le #9536321
------=_Part_5773_13431152.1175593634355
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Je viens de regler mon probleme de configuration des modules de cette
maniere la:

apt-get install libtool

configure.in :
(--) AC_PROG_RANLIB
(++) AC_PROB_LIBTOOL

et dans le Makefile.am d'un des modules:

lib_LTLIBRARIES = libname.la

libname_la_SOURCES =
header1.h
source1.cpp
header2.h
source2.cpp

libname_la_LDFLAGS = -version-info 1:0:0

INCLUDES = @/src/include

Par contre j'ai toujours le probleme au moment du load des modules qui ne
trouvent pas certains symbols qui seraient senses etre exportes par le core
au moment de la compilation grace a un -Wl--export-dynamic


--
105 116 039 115 032 110 111 116 032 097
032 098 117 103 044 032 105 116 039 115
032 097 032 102 101 097 116 117 114 101

------=_Part_5773_13431152.1175593634355
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Je viens de regler mon probleme de configuration des modules de cette maniere la: et dans le <br><br><br>-- <br>105 116 039 115 032 110 111 116 032 097<br>032 098 117 103 044 032 105 116 039 115<br>032 097 032 102 101 097 116 117 114 101

------=_Part_5773_13431152.1175593634355--


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Cédric Lucantis
Le #9536301
Le mardi 3 avril 2007 11:47, Heyberger Ludovic a écrit :
Je viens de regler mon probleme de configuration des modules de cette
maniere la:

apt-get install libtool

configure.in :
(--) AC_PROG_RANLIB
(++) AC_PROB_LIBTOOL

et dans le Makefile.am d'un des modules:

lib_LTLIBRARIES = libname.la

libname_la_SOURCES =
header1.h
source1.cpp
header2.h
source2.cpp

libname_la_LDFLAGS = -version-info 1:0:0

INCLUDES = @/src/include

Par contre j'ai toujours le probleme au moment du load des modules qui ne
trouvent pas certains symbols qui seraient senses etre exportes par le co re
au moment de la compilation grace a un -Wl--export-dynamic



Il y a une virgule ici: -Wl,--export-dynamic (je ne sais pas si c'est
obligatoire) mais pourquoi en as tu besoin? J'ai un projet à base de modu les
dynamiques qui fonctionne très bien sans.

As tu lancé libtoolize? (peut être qu'un make maintainer-clean aiderait aussi)

Sinon c'est pas très clair, comment compiles tu les modules et comment le s
utilises tu ? (avec lt_dlopen?) Le makefile complet serait utile (si il ne
fait pas 15 pages :)

Normalement, tu devrais avoir quelque chose comme ca:

# bibliothèque principale
lib_LTLIBRARIES = libmain.la
libmain_LIBADD = -lltdl
libmain_SOURCES = ...

# module
modulesdir = ...
modules_LTLIBRARIES = module1.la
module1_la_LDFLAGS = -module
module1_SOURCES = ...

--
Cédric Lucantis
Heyberger Ludovic
Le #9536281
------=_Part_8127_21114924.1175603787090
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


Il y a une virgule ici: -Wl,--export-dynamic (je ne sais pas si c'est
obligatoire) mais pourquoi en as tu besoin?




oui, je tappait ca de tete ;-) mais la virgule est bien presente

J'ai un projet à base de modules dynamiques qui fonctionne très bien sa ns.


en fait dans l'idee, les modules utilisent des symboles tels que des
singletons qui sont definis dans le core du serveur et le --export-dynamic
permet de resoudre ces symboles uniquement au loading du module en allant
tapper dans ceux du serveur.
C'est tout du moins le fonctionnement auquel j'etait parvenu en utilisant u n
Makefile a la mano dans lequel je precisait juste l'export-dynamic au momen t
du link (la difference etait que tout les .o etaient compiles et ensuite il s
etaient tous linkes d'un coup -- ca ne passait pas par des librairies
temporares comme c'est le cas avec mes Makefiles.am)

As tu lancé libtoolize? (peut être qu'un make maintainer-clean aiderait
aussi)




J'ai lance un libtoolize, mais je n'ai pas vu beaucoup de difference (il n' y
a pas eu d'output). Je testerait le make maintainer-clean, mais a chaque
fois que je fait un test, je recompile tout les objs (le core du serveur et
le module que je test ne sont pas tres longs a compiler)

Sinon c'est pas très clair, comment compiles tu les modules et comment le s
utilises tu ? (avec lt_dlopen?) Le makefile complet serait utile (si il n e
fait pas 15 pages :)




Voici donc les extraits de mes differents fichiers :


* Configure.in a la racine du projet:

AC_INIT(Core, 1.0, )
AM_INIT_AUTOMAKE(Core, 1.0)
AC_PROG_CXX
AC_PROG_LIBTOOL
AC_DEFINE(TIXML_USE_STL)
AC_DEFINE(BOOST_ALL_NO_LIB)
AC_PROG_INSTALL
AC_OUTPUT(
./Makefile
./src/Makefile
./src/core/Makefile
./src/core/common/Makefile
./src/include/Makefile
./src/modules/Makefile
./src/modules/module1/Makefile
)


* Le Makefile.am a la racine

SUBDIRS = src


* Le Makefile.am dans ./src

SUBDIRS =
core
include
modules

* Le Makefile.am dans ./src/core (c'est la ou la compile du core se fait,
et c'est la qu'il y a le main.cpp et les sous repertoires qui separent le
code du core. je simplifie l'arborescence pour des questions de lisibilite)

SUBDIRS = common

bindir = @prefix@/bin
bin_PROGRAMS = core

coredir = @prefix@/bin
core_SOURCES = main.cpp

core_LDADD = common/libcorecommon.a

INCLUDES =
@/src/include
-I./common

LIBS = -lpthread -ldl -Wl,--export-dynamic


* Le Makefile.am dans le repertoire ./src/core/common/ (celui qui est sens e
compiler la libcorecommon.a qui sera linkee ensuite avec le main.cpp (.o) )
-- C'est dans ce repertoire que le Parser et le Logger sont des singletons
et donc j'aurais besoin que les symboles soient accessibles depuis mes
modules.

noinst_LIBRARIES = libcorecommon.a

libcorecommon_a_SOURCES =
Parser.h
Parser.cpp
Logger.h
Logger.cpp
Utils.h
Utils.cpp

INCLUDES = @/src/include/

* et enfin le Makefile.am d'un des modules ( ./src/modules/module1/ )

lib_LTLIBRARIES = mod1.la

mod1_la_SOURCES =
header1.h
source1.cpp
header2.h
source2.cpp

mod1_la_LDFLAGS = -version-info 1:0:0

INCLUDES =
@/src/include
@/src/core/common


Voila, je pense que le probleme viens d'un de mes fichiers ou d'une etape
que je fait mal, mais comme je suis debutant en Autotools, je ne suis pas
encore au fait des bonnes pratiques.

deux questions bonus pour terminer :
1) pour resoudre mon probleme de compilation et d'export-dynamic je pourrai s
passer par un Makefile.am dans ./src/core/ qui compilerait tout mes fichier s
(meme ceux qui sont dans des sous-repertoires) en une seule fois. mais
est-ce vraiment propre?
2) quelles difference entre automake-autoconf-libtool et autotools? les
premiers font-ils partie du second?

Merci d'avance

--
105 116 039 115 032 110 111 116 032 097
032 098 117 103 044 032 105 116 039 115
032 097 032 102 101 097 116 117 114 101

------=_Part_8127_21114924.1175603787090
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

J&#39;ai un projet à base de modules dynamiques qui fonctionne très bie n sans.</blockquote><div><br>en fait dans l&#39;idee, les modules utilisent des symboles tels que des singletons qui sont definis dans le core du serv eur et le --export-dynamic permet de resoudre ces symboles uniquement au lo ading du module en allant tapper dans ceux du serveur.
<br>C&#39;est tout du moins le fonctionnement auquel j&#39;etait parvenu en utilisant un Makefile a la mano dans lequel je precisait juste l&#39;expor t-dynamic au moment du link (la difference etait que tout les .o etaient co mpiles et ensuite ils etaient tous linkes d&#39;un coup -- ca ne passait pa s par des librairies temporares comme c&#39;est le cas avec mes
</blockquote><div><br>J&#39;ai lance un libtoolize, mais je n&#39;ai pas vu beaucoup de difference (il n&#39;y a pas eu d&#39;output). Je testerait le make maintainer-clean, mais a chaque fois que je fait un test, je recompil e tout les objs (le core du serveur et le module que je test ne sont pas tr es longs a compiler)&nbsp;
utilises tu ? (avec lt_dlopen?) Le makefile complet serait utile (si il ne AC_DEFINE(BOOST_ALL_NO_LIB) SUBDIRS = INCLUDES&nbsp;&nbsp;&nbsp; = libcorecommon.a qui sera linkee ensuite avec le main.cpp (.o) ) -- C&#39;es t dans ce repertoire que le Parser et le Logger sont des singletons et donc j&#39;aurais besoin que les symboles soient accessibles depuis mes modules .
mod1.la &nbsp;&nbsp;&nbsp; @/src/core/common<br><br></div></div><br>Vo ila, je pense que le probleme viens d&#39;un de mes fichiers ou d&#39;une e tape que je fait mal, mais comme je suis debutant en Autotools, je ne suis pas encore au fait des bonnes pratiques.
<br>2) quelles difference entre automake-autoconf-libtool et autotools? les premiers font-ils partie du second?<br><br>Merci d&#39;avance<br><br>-- <b r>105 116 039 115 032 110 111 116 032 097<br>032 098 117 103 044 032 105 11 6 039 115
<br>032 097 032 102 101 097 116 117 114 101

------=_Part_8127_21114924.1175603787090--


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Cédric Lucantis
Le #9535971
> en fait dans l'idee, les modules utilisent des symboles tels que des
singletons qui sont definis dans le core du serveur et le --export-dynamic
permet de resoudre ces symboles uniquement au loading du module en allant
tapper dans ceux du serveur.
C'est tout du moins le fonctionnement auquel j'etait parvenu en utilisant
un Makefile a la mano dans lequel je precisait juste l'export-dynamic au
moment du link (la difference etait que tout les .o etaient compiles et
ensuite ils etaient tous linkes d'un coup -- ca ne passait pas par des
librairies temporares comme c'est le cas avec mes Makefiles.am)



Les modules ne devraient pas avoir à acceder au programme lui-même, mai s
seulement à la librairie corecommon. Si tu as des ressources globales
utilisables par les modules, elles doivent être fournies par la librairie s.


As tu lancé libtoolize? (peut être qu'un make maintainer-clean aidera it

> aussi)

J'ai lance un libtoolize, mais je n'ai pas vu beaucoup de difference (il
n'y a pas eu d'output). Je testerait le make maintainer-clean, mais a
chaque fois que je fait un test, je recompile tout les objs (le core du
serveur et le module que je test ne sont pas tres longs a compiler)



ca peut vraiment aider quand tu fais des gros changements dans la config,
beaucoup de choses devraient être recompilées et ne le sont pas (les
dépendences ne tiennent compte que des fichiers sources)


* Le Makefile.am dans ./src/core (c'est la ou la compile du core se fait,
et c'est la qu'il y a le main.cpp et les sous repertoires qui separent le
code du core. je simplifie l'arborescence pour des questions de lisibilit e)

SUBDIRS = common

bindir = @prefix@/bin
bin_PROGRAMS = core

coredir = @prefix@/bin
core_SOURCES = main.cpp

core_LDADD = common/libcorecommon.a

INCLUDES =
@/src/include
-I./common

LIBS = -lpthread -ldl -Wl,--export-dynamic



j'enleverais cette ligne pour la remplacer par LIBADD (voir plus bas)



* Le Makefile.am dans le repertoire ./src/core/common/ (celui qui est
sense compiler la libcorecommon.a qui sera linkee ensuite avec le main.cpp
(.o) ) -- C'est dans ce repertoire que le Parser et le Logger sont des
singletons et donc j'aurais besoin que les symboles soient accessibles
depuis mes modules.

noinst_LIBRARIES = libcorecommon.a



pendant qu'on y est, pourquoi pas une lib dynamique ici aussi?


libcorecommon_a_SOURCES =
Parser.h
Parser.cpp
Logger.h
Logger.cpp
Utils.h
Utils.cpp



libcorecommon_la_LIBADD = -lpthread -ldl

attention LIBADD, et pas LDADD! avec ça, lpthread et ldl seront ajoutée s
automatiquement à chaque fois que tu link quelque chose avec -lcorecommon.


INCLUDES = @/src/include/

* et enfin le Makefile.am d'un des modules ( ./src/modules/module1/ )

lib_LTLIBRARIES = mod1.la

mod1_la_SOURCES =
header1.h
source1.cpp
header2.h
source2.cpp

mod1_la_LDFLAGS = -version-info 1:0:0



il faut ajouter -module aux LDFLAGS pour que libtool accepte de créer une
librairie non-standard

et puis ça:

mod1_la_LIBADD = $(top_builddir)/core/common/lib/libcorecommon.la

meme chose qu'au dessus, ça devrait régler le probleme du --export-dyna mic


INCLUDES =
@/src/include
@/src/core/common


Voila, je pense que le probleme viens d'un de mes fichiers ou d'une etape
que je fait mal, mais comme je suis debutant en Autotools, je ne suis pas
encore au fait des bonnes pratiques.



le probleme, c'est que les docs sont eparpillées un peu partout et pas
évidentes à trouver, et les recents problemes de licence debian n'ont p as
arrangé les choses (certain manuels sont en non-free). Le mieux c'est d'a ller
sur les sites respectifs, tu trouveras un manuel complet pour chaque outil,
plus un livre (autobook) qui décrit l'ensemble.


deux questions bonus pour terminer :



1) pour resoudre mon probleme de compilation et d'export-dynamic je
pourrais passer par un Makefile.am dans ./src/core/ qui compilerait tout
mes fichiers (meme ceux qui sont dans des sous-repertoires) en une seule
fois. mais est-ce vraiment propre?



pas vraiment, c'est pas du tout l'esprit d'automake et tu aurais des probl èmes
avec les variables _SOURCES qui n'acceptent pas des fichiers venant d'un
autre repertoire.

2) quelles difference entre automake-autoconf-libtool et autotools? les
premiers font-ils partie du second?



en gros oui, autotools est seulement un nom donné à l'ensemble des outi ls de
compilation GNU (automake, autoconf, libtool, m4)

--
Cédric Lucantis
Heyberger Ludovic
Le #9535931
------=_Part_28584_6518382.1175691029392
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


Les modules ne devraient pas avoir à acceder au programme lui-même, m ais
seulement à la librairie corecommon. Si tu as des ressources globales
utilisables par les modules, elles doivent être fournies par la
librairies.




on s'est longtemps pose la question de si on allait faire une libruntime ou
pas, et puis on est arrive a la conclusion que mettre des singletons dans
une dll/so c'etait pas le top, c'est pour ca qu'on a tout migre cote
serveur, et qu'on a reintegre notre libruntime au serveur.


1) pour resoudre mon probleme de compilation et d'export-dynamic je
> pourrais passer par un Makefile.am dans ./src/core/ qui compilerait tou t
> mes fichiers (meme ceux qui sont dans des sous-repertoires) en une seul e
> fois. mais est-ce vraiment propre?

pas vraiment, c'est pas du tout l'esprit d'automake et tu aurais des
problèmes
avec les variables _SOURCES qui n'acceptent pas des fichiers venant d'un
autre repertoire.




pour continuer a avancer sans rester bloque sur ce probleme, j'ai passe les
differents makefile.am en un seul gros makefile.am a la racine du core, ce
qui permet de linker tout le code d'un coup avec le export-dynamic et qui d u
coup m'a resolu mon probleme. je suis conscient que c'est pas vraiment
l'esprit d'automake et cie mais ca m'a permis de continuer a avancer.
je verrais a repasser le tout en differents makefiles des que j'aurais un
peu de temps. a ce moment la, je pense que je suivrait tes conseils a la
lettre histoire de ne pas rencontrer d'autres problemes.

Merci pour ton aide !

--
105 116 039 115 032 110 111 116 032 097
032 098 117 103 044 032 105 116 039 115
032 097 032 102 101 097 116 117 114 101

------=_Part_28584_6518382.1175691029392
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br>Merci pour ton aide !<br><br></div>-- <br>105 116 039 115 032 110 111 1 16 032 097<br>032 098 117 103 044 032 105 116 039 115<br>032 097 032 102 10 1 097 116 117 114 101

------=_Part_28584_6518382.1175691029392--


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Publicité
Poster une réponse
Anonyme