> 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, mais seulement à la librairie corecommon. Si tu as des ressources globales utilisables par les modules, elles doivent être fournies par la librairies. > > 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) 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 lisibilite) > > SUBDIRS = common > > bindir = @prefix@/bin > bin_PROGRAMS = core > > coredir = @prefix@/bin > core_SOURCES = main.cpp > > core_LDADD = common/libcorecommon.a > > INCLUDES = \ > [EMAIL PROTECTED]@/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ées automatiquement à chaque fois que tu link quelque chose avec -lcorecommon. > > INCLUDES = [EMAIL PROTECTED]@/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-dynamic > > INCLUDES = \ > [EMAIL PROTECTED]@/src/include \ > [EMAIL PROTECTED]@/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 pas arrangé les choses (certain manuels sont en non-free). Le mieux c'est d'aller 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 outils de compilation GNU (automake, autoconf, libtool, m4) -- Cédric Lucantis
