probleme autoconf automake

Cédric Lucantis

01/04/2007 à 17:50

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

01/04/2007 à 20:40

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

01/04/2007 à 23:10

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

02/04/2007 à 10:20

------=_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 wrote:

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'avancement a ce moment la! <div>On 4/1/07, Cédric Lucantis <
<a href="mailto:"></a>> wrote:<bl ockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204 , 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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 dist ribuer un programme de type serveur modulaire et je > rencontre pas m al de problemes depuis le debut.
 > > mon architecture de repertoire est la suivante: > > ... > > donc j'ai suivi les indications de divers tut os expliquants que pour > compiler, je devais passer par autant de li bs statiques que de sous
 > repertoires necessaires a ma compile. j'ai donc les fichiers s uivants: > > ... > > que je link ensuite a mon main .o grace a la macro LDADD C'est plutôt LIBADD dans ce cas je c rois, 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 pos sedant 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 ép arpillé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 librai ries statiques et/ou dynamiques selon ce que veut l'utilisateur et c e 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 : liblt dl (voir info libtool). Ca a l'air d'être ce que tu cherches.. . 
 -- Cédric Lucantis </blockquote></div> -- 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--

--
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

------=_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 <omer@no-log.org> wrote:

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'avancement a ce moment la! <div>On 4/1/07, Cédric Lucantis <
<a href="mailto:omer@no-log.org">omer@no-log.org</a>> wrote:<bl ockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204 , 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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 dist ribuer un programme de type serveur modulaire et je > rencontre pas m al de problemes depuis le debut.
 > > mon architecture de repertoire est la suivante: > > ... > > donc j'ai suivi les indications de divers tut os expliquants que pour > compiler, je devais passer par autant de li bs statiques que de sous
 > repertoires necessaires a ma compile. j'ai donc les fichiers s uivants: > > ... > > que je link ensuite a mon main .o grace a la macro LDADD C'est plutôt LIBADD dans ce cas je c rois, 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 pos sedant 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 ép arpillé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 librai ries statiques et/ou dynamiques selon ce que veut l'utilisateur et c e 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 : liblt dl (voir info libtool). Ca a l'air d'être ce que tu cherches.. . 
 -- Cédric Lucantis </blockquote></div> -- 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--

--
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

Vous avez filtré cet utilisateur ! Consultez son message

------=_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 wrote:

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'avancement a ce moment la! <div>On 4/1/07, Cédric Lucantis <
<a href="mailto:"></a>> wrote:<bl ockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204 , 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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 dist ribuer un programme de type serveur modulaire et je > rencontre pas m al de problemes depuis le debut.
 > > mon architecture de repertoire est la suivante: > > ... > > donc j'ai suivi les indications de divers tut os expliquants que pour > compiler, je devais passer par autant de li bs statiques que de sous
 > repertoires necessaires a ma compile. j'ai donc les fichiers s uivants: > > ... > > que je link ensuite a mon main .o grace a la macro LDADD C'est plutôt LIBADD dans ce cas je c rois, 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 pos sedant 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 ép arpillé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 librai ries statiques et/ou dynamiques selon ce que veut l'utilisateur et c e 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 : liblt dl (voir info libtool). Ca a l'air d'être ce que tu cherches.. . 
 -- Cédric Lucantis </blockquote></div> -- 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--

--
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

03/04/2007 à 11:50

------=_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: apt-get install libtool <a href="http://configure.in">configure.in</a> : (--) AC_PROG_RANLIB (++) AC_PROB_LIBTOOL 
et dans le <a href="http://Makefile.am">Makefile.am</a> d'un des modules: lib_LTLIBRARIES = <a href="http://libname.la">libname.la</a> 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--

--
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

------=_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 = -I@top_srcdir@/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: apt-get install libtool <a href="http://configure.in">configure.in</a> : (--) AC_PROG_RANLIB (++) AC_PROB_LIBTOOL 
et dans le <a href="http://Makefile.am">Makefile.am</a> d'un des modules: lib_LTLIBRARIES = <a href="http://libname.la">libname.la</a> libname_la_SOURCES  =     header1.h          source1.cpp   
     header2.h         source2.cpp libname_la_LDFLAGS  = -version-info 1:0:0 INCLUDES  =  -I@top_srcdir@/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--

--
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

Vous avez filtré cet utilisateur ! Consultez son message

------=_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: apt-get install libtool <a href="http://configure.in">configure.in</a> : (--) AC_PROG_RANLIB (++) AC_PROB_LIBTOOL 
et dans le <a href="http://Makefile.am">Makefile.am</a> d'un des modules: lib_LTLIBRARIES = <a href="http://libname.la">libname.la</a> 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--

--
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

03/04/2007 à 13:40

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

03/04/2007 à 14:40

------=_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

<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb( 204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Il y a une v irgule ici: -Wl,--export-dynamic (je ne sais pas si c'est obligatoir e) mais pourquoi en as tu besoin?
</blockquote><div> oui, je tappait ca de tete ;-) mais la virgule est bi en presente </div> <blockquote class="gmail_quote" style="border -left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-lef t: 1ex;">
J'ai un projet à base de modules dynamiques qui fonctionne très bie n sans.</blockquote><div> en fait dans l'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.
 C'est tout du moins le fonctionnement auquel j'etait parvenu en utilisant un Makefile a la mano dans lequel je precisait juste l'expor t-dynamic au moment du link (la difference etait que tout les .o etaient co mpiles et ensuite ils etaient tous linkes d'un coup -- ca ne passait pa s par des librairies temporares comme c'est le cas avec mes
<a href="http://Makefiles.am">Makefiles.am</a>) </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); m argin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">As tu lancé libtoolize? (pe ut être qu'un make maintainer-clean aiderait aussi)
</blockquote><div> 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 recompil e tout les objs (le core du serveur et le module que je test ne sont pas tr es longs a compiler) 
</div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Sinon c 'est pas très clair, comment compiles tu les modules et comment les
utilises tu ? (avec lt_dlopen?) Le makefile complet serait utile (si il ne fait pas 15 pages :)</blockquote><div> Voici donc les extraits de mes differents fichiers :  * <a href="http://Configure.in">C onfigure.in
</a> a la racine du projet: AC_INIT(Core, 1.0, <a href="mailto:bug "></a>) 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(  &nb sp;  ./Makefile     ./src/Makefile  &nbs p;  ./src/core/Makefile     ./src/core/common/Make file     ./src/include/Makefile     ./src/modules/Makefile
     ./src/modules/module1/Makefile   &nbs p; ) * Le <a href="http://Makefile.am">Makefile.am</a> a la ra cine SUBDIRS = src  * Le <a href="http://Makefil e.am">Makefile.am</a> dans ./src 
SUBDIRS =     core     include     modules  * Le <a href="http://Makefile. am">Makefile.am</a> 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 questio ns de lisibilite)
 SUBDIRS = common bindir      &nbs p;     = @prefix@/bin bin_PROGRAMS    = core coredir          &n bsp; = @prefix@/bin core_SOURCES        = main.cpp core_LDADD        = com mon/libcorecommon.a 
INCLUDES    =     @/src/i nclude     -I./common LIBS    = -lpthread -ldl -Wl,--export-dynamic  * Le <a href="http: //Makefile.am">Makefile.am</a> dans le repertoire ./src/core/common/ (celui qui est sense compiler la
libcorecommon.a qui sera linkee ensuite avec le main.cpp (.o) ) -- C'es t 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             &nb sp;      Logger.cpp                     Utils. h              &nbsp ;    
     Utils.cpp INCLUDES    = op_srcdir@/src/include/  * et enfin le <a href="http://Makefi le.am">Makefile.am</a> d'un des modules ( ./src/modules/module1/ ) lib_LTLIBRARIES    = <a href="http://mod1.la">
mod1.la</a> mod1_la_SOURCES =     header1.h     source1.cpp     header2.h &n bsp;   source2.cpp mod1_la_LDFLAGS    = - version-info 1:0:0 INCLUDES =     r@/src/include 
    @/src/core/common </div></div> Vo ila, je pense que le probleme viens d'un de mes fichiers ou d'une e tape 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 proble me de compilation et d'export-dynamic je pourrais passer par un <a href ="http://Makefile.am">Makefile.am</a> dans ./src/core/ qui compilerait to ut mes fichiers (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 11 6 039 115
 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

------=_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, bug-report@mailinator.org)
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 =
-I@top_srcdir@/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 = -I@top_srcdir@/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 =
-I@top_srcdir@/src/include
-I@top_srcdir@/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

<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb( 204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Il y a une v irgule ici: -Wl,--export-dynamic (je ne sais pas si c'est obligatoir e) mais pourquoi en as tu besoin?
</blockquote><div> oui, je tappait ca de tete ;-) mais la virgule est bi en presente </div> <blockquote class="gmail_quote" style="border -left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-lef t: 1ex;">
J'ai un projet à base de modules dynamiques qui fonctionne très bie n sans.</blockquote><div> en fait dans l'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.
 C'est tout du moins le fonctionnement auquel j'etait parvenu en utilisant un Makefile a la mano dans lequel je precisait juste l'expor t-dynamic au moment du link (la difference etait que tout les .o etaient co mpiles et ensuite ils etaient tous linkes d'un coup -- ca ne passait pa s par des librairies temporares comme c'est le cas avec mes
<a href="http://Makefiles.am">Makefiles.am</a>) </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); m argin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">As tu lancé libtoolize? (pe ut être qu'un make maintainer-clean aiderait aussi)
</blockquote><div> 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 recompil e tout les objs (le core du serveur et le module que je test ne sont pas tr es longs a compiler) 
</div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Sinon c 'est pas très clair, comment compiles tu les modules et comment les
utilises tu ? (avec lt_dlopen?) Le makefile complet serait utile (si il ne fait pas 15 pages :)</blockquote><div> Voici donc les extraits de mes differents fichiers :  * <a href="http://Configure.in">C onfigure.in
</a> a la racine du projet: AC_INIT(Core, 1.0, <a href="mailto:bug -report@mailinator.org">bug-report@mailinator.org</a>) 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(  &nb sp;  ./Makefile     ./src/Makefile  &nbs p;  ./src/core/Makefile     ./src/core/common/Make file     ./src/include/Makefile     ./src/modules/Makefile
     ./src/modules/module1/Makefile   &nbs p; ) * Le <a href="http://Makefile.am">Makefile.am</a> a la ra cine SUBDIRS = src  * Le <a href="http://Makefil e.am">Makefile.am</a> dans ./src 
SUBDIRS =     core     include     modules  * Le <a href="http://Makefile. am">Makefile.am</a> 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 questio ns de lisibilite)
 SUBDIRS = common bindir      &nbs p;     = @prefix@/bin bin_PROGRAMS    = core coredir          &n bsp; = @prefix@/bin core_SOURCES        = main.cpp core_LDADD        = com mon/libcorecommon.a 
INCLUDES    =     -I@top_srcdir@/src/i nclude     -I./common LIBS    = -lpthread -ldl -Wl,--export-dynamic  * Le <a href="http: //Makefile.am">Makefile.am</a> dans le repertoire ./src/core/common/ (celui qui est sense compiler la
libcorecommon.a qui sera linkee ensuite avec le main.cpp (.o) ) -- C'es t 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             &nb sp;      Logger.cpp                     Utils. h              &nbsp ;    
     Utils.cpp INCLUDES    = -I@t op_srcdir@/src/include/  * et enfin le <a href="http://Makefi le.am">Makefile.am</a> d'un des modules ( ./src/modules/module1/ ) lib_LTLIBRARIES    = <a href="http://mod1.la">
mod1.la</a> mod1_la_SOURCES =     header1.h     source1.cpp     header2.h &n bsp;   source2.cpp mod1_la_LDFLAGS    = - version-info 1:0:0 INCLUDES =     -I@top_srcdi r@/src/include 
    -I@top_srcdir@/src/core/common </div></div> Vo ila, je pense que le probleme viens d'un de mes fichiers ou d'une e tape 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 proble me de compilation et d'export-dynamic je pourrais passer par un <a href ="http://Makefile.am">Makefile.am</a> dans ./src/core/ qui compilerait to ut mes fichiers (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 11 6 039 115
 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 debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Vous avez filtré cet utilisateur ! Consultez son message

------=_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

<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb( 204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Il y a une v irgule ici: -Wl,--export-dynamic (je ne sais pas si c'est obligatoir e) mais pourquoi en as tu besoin?
</blockquote><div> oui, je tappait ca de tete ;-) mais la virgule est bi en presente </div> <blockquote class="gmail_quote" style="border -left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-lef t: 1ex;">
J'ai un projet à base de modules dynamiques qui fonctionne très bie n sans.</blockquote><div> en fait dans l'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.
 C'est tout du moins le fonctionnement auquel j'etait parvenu en utilisant un Makefile a la mano dans lequel je precisait juste l'expor t-dynamic au moment du link (la difference etait que tout les .o etaient co mpiles et ensuite ils etaient tous linkes d'un coup -- ca ne passait pa s par des librairies temporares comme c'est le cas avec mes
<a href="http://Makefiles.am">Makefiles.am</a>) </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); m argin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">As tu lancé libtoolize? (pe ut être qu'un make maintainer-clean aiderait aussi)
</blockquote><div> 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 recompil e tout les objs (le core du serveur et le module que je test ne sont pas tr es longs a compiler) 
</div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Sinon c 'est pas très clair, comment compiles tu les modules et comment les
utilises tu ? (avec lt_dlopen?) Le makefile complet serait utile (si il ne fait pas 15 pages :)</blockquote><div> Voici donc les extraits de mes differents fichiers :  * <a href="http://Configure.in">C onfigure.in
</a> a la racine du projet: AC_INIT(Core, 1.0, <a href="mailto:bug "></a>) 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(  &nb sp;  ./Makefile     ./src/Makefile  &nbs p;  ./src/core/Makefile     ./src/core/common/Make file     ./src/include/Makefile     ./src/modules/Makefile
     ./src/modules/module1/Makefile   &nbs p; ) * Le <a href="http://Makefile.am">Makefile.am</a> a la ra cine SUBDIRS = src  * Le <a href="http://Makefil e.am">Makefile.am</a> dans ./src 
SUBDIRS =     core     include     modules  * Le <a href="http://Makefile. am">Makefile.am</a> 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 questio ns de lisibilite)
 SUBDIRS = common bindir      &nbs p;     = @prefix@/bin bin_PROGRAMS    = core coredir          &n bsp; = @prefix@/bin core_SOURCES        = main.cpp core_LDADD        = com mon/libcorecommon.a 
INCLUDES    =     @/src/i nclude     -I./common LIBS    = -lpthread -ldl -Wl,--export-dynamic  * Le <a href="http: //Makefile.am">Makefile.am</a> dans le repertoire ./src/core/common/ (celui qui est sense compiler la
libcorecommon.a qui sera linkee ensuite avec le main.cpp (.o) ) -- C'es t 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             &nb sp;      Logger.cpp                     Utils. h              &nbsp ;    
     Utils.cpp INCLUDES    = op_srcdir@/src/include/  * et enfin le <a href="http://Makefi le.am">Makefile.am</a> d'un des modules ( ./src/modules/module1/ ) lib_LTLIBRARIES    = <a href="http://mod1.la">
mod1.la</a> mod1_la_SOURCES =     header1.h     source1.cpp     header2.h &n bsp;   source2.cpp mod1_la_LDFLAGS    = - version-info 1:0:0 INCLUDES =     r@/src/include 
    @/src/core/common </div></div> Vo ila, je pense que le probleme viens d'un de mes fichiers ou d'une e tape 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 proble me de compilation et d'export-dynamic je pourrais passer par un <a href ="http://Makefile.am">Makefile.am</a> dans ./src/core/ qui compilerait to ut mes fichiers (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 11 6 039 115
 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

04/04/2007 à 14:40

> 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

> 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 =
-I@top_srcdir@/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 = -I@top_srcdir@/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 =
-I@top_srcdir@/src/include
-I@top_srcdir@/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

Vous avez filtré cet utilisateur ! Consultez son message

> 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

04/04/2007 à 15:00

------=_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

<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb( 204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Les modules ne devraient pas avoir à acceder au programme lui-même, mais seuleme nt à la librairie corecommon. Si tu as des ressources globales
 utilisables par les modules, elles doivent être fournies par la libra iries.</blockquote><div> on s'est longtemps pose la question de si o n 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'es t pour ca qu'on a tout migre cote serveur, et qu'on a reintegre not re libruntime au serveur.
 </div><div> </div> <blockquote class="gmail_quote" style="bor der-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding- left: 1ex;">> 1) pour resoudre mon probleme de compilation et d'expo rt-dynamic je
 > pourrais passer par un <a href="http://Makefile.am">Makefile.am< /a> dans ./src/core/ qui compilerait tout > mes fichiers (meme ceux q ui sont dans des sous-repertoires) en une seule > fois. mais est-ce v raiment propre?
 pas vraiment, c'est pas du tout l'esprit d'automake et tu aurais des problèmes avec les variables _SOURCES qui n'accepten t pas des fichiers venant d'un autre repertoire.</blockquote><div>
 pour continuer a avancer sans rester bloque sur ce probleme, j'ai p asse les differents <a href="http://makefile.am">makefile.am</a> en un se ul gros <a href="http://makefile.am">makefile.am</a> a la racine du core, ce qui permet de linker tout le code d'un coup avec le export-dynamic et qui du 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'aur ais 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. </div>
 Merci pour ton aide ! </div>-- 105 116 039 115 032 110 111 1 16 032 097 032 098 117 103 044 032 105 116 039 115 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

------=_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

<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb( 204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Les modules ne devraient pas avoir à acceder au programme lui-même, mais seuleme nt à la librairie corecommon. Si tu as des ressources globales
 utilisables par les modules, elles doivent être fournies par la libra iries.</blockquote><div> on s'est longtemps pose la question de si o n 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'es t pour ca qu'on a tout migre cote serveur, et qu'on a reintegre not re libruntime au serveur.
 </div><div> </div> <blockquote class="gmail_quote" style="bor der-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding- left: 1ex;">> 1) pour resoudre mon probleme de compilation et d'expo rt-dynamic je
 > pourrais passer par un <a href="http://Makefile.am">Makefile.am< /a> dans ./src/core/ qui compilerait tout > mes fichiers (meme ceux q ui sont dans des sous-repertoires) en une seule > fois. mais est-ce v raiment propre?
 pas vraiment, c'est pas du tout l'esprit d'automake et tu aurais des problèmes avec les variables _SOURCES qui n'accepten t pas des fichiers venant d'un autre repertoire.</blockquote><div>
 pour continuer a avancer sans rester bloque sur ce probleme, j'ai p asse les differents <a href="http://makefile.am">makefile.am</a> en un se ul gros <a href="http://makefile.am">makefile.am</a> a la racine du core, ce qui permet de linker tout le code d'un coup avec le export-dynamic et qui du 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'aur ais 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. </div>
 Merci pour ton aide ! </div>-- 105 116 039 115 032 110 111 1 16 032 097 032 098 117 103 044 032 105 116 039 115 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 debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Vous avez filtré cet utilisateur ! Consultez son message

------=_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

<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb( 204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Les modules ne devraient pas avoir à acceder au programme lui-même, mais seuleme nt à la librairie corecommon. Si tu as des ressources globales
 utilisables par les modules, elles doivent être fournies par la libra iries.</blockquote><div> on s'est longtemps pose la question de si o n 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'es t pour ca qu'on a tout migre cote serveur, et qu'on a reintegre not re libruntime au serveur.
 </div><div> </div> <blockquote class="gmail_quote" style="bor der-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding- left: 1ex;">> 1) pour resoudre mon probleme de compilation et d'expo rt-dynamic je
 > pourrais passer par un <a href="http://Makefile.am">Makefile.am< /a> dans ./src/core/ qui compilerait tout > mes fichiers (meme ceux q ui sont dans des sous-repertoires) en une seule > fois. mais est-ce v raiment propre?
 pas vraiment, c'est pas du tout l'esprit d'automake et tu aurais des problèmes avec les variables _SOURCES qui n'accepten t pas des fichiers venant d'un autre repertoire.</blockquote><div>
 pour continuer a avancer sans rester bloque sur ce probleme, j'ai p asse les differents <a href="http://makefile.am">makefile.am</a> en un se ul gros <a href="http://makefile.am">makefile.am</a> a la racine du core, ce qui permet de linker tout le code d'un coup avec le export-dynamic et qui du 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'aur ais 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. </div>
 Merci pour ton aide ! </div>-- 105 116 039 115 032 110 111 1 16 032 097 032 098 117 103 044 032 105 116 039 115 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

probleme autoconf automake

9 réponses

Veuillez sélectionner un problème