[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
automatic linker dependencies for helper-libs to solve undefined referen
From: |
Christian Nolte |
Subject: |
automatic linker dependencies for helper-libs to solve undefined references? |
Date: |
Tue, 15 Nov 2005 14:53:48 +0100 |
User-agent: |
Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I am really struggling on migrating a M$-VC project to an automake based
one. This project has a deep folder-structure and really ugly
dependencies over boundaries of the subfolders. For example:
- ---
./project
project/utils
project/utils/console
project/gfx
project/main
...
- ---
So in this example it could be that the helper lib for
folder project/utils/console has dependencies to project/gfx or
project/main needs something from project/utils which itself needs
project/console.
I understand that automake needs helper-libs to create Makefiles for
subfolders. For every subfolder I create a helper-lib, for example for
project/utils I write in the corresponding Makefile.am:
- ---
SUBDIRS = console
noinst_LIBRARIES = libutils.a
libutils_a_SOURCES = A.h A.cpp B.h B.cpp
noinst_HEADERS = A.h B.h
- ---
The only binary which shall come out lies in project/main. The
Makefile.am there looks like this:
- ---
noinst_LIBRARIES = libmain.a
libmain_a_SOURCES = A.h A.cpp B.h B.cpp
libmain_a_LIBADD =
noinst_PROGRAMS = project
project_SOURCES = main.cpp
project_LDADD = $(top_builddir)/project/main/libmain.a \
$(top_builddir)/project/utils/libutils.a \
$(top_builddir)/project/utils/console/libconsole.a \
$(top_builddir)/project/gfx/libgfx.a \
$(top_builddir)/project/main \
-lm -lpthread
- ---
I have managed to create my Makefile.am's so that I get a compile-run
without errors but several 'undefined references' at the linker-stage.
As the project is a huge one with complex dependencies, I am struggling
to get the order of library-dependencies right.
The last thing I tried was to reduce the dependencies for the
project-binary in that I define the LDADD's for every top-directory so
that it contains the sub-directory helper libs. In this example it boils
down to:
- --- Makefile.am of project/utils:
SUBDIRS = console
noinst_LIBRARIES = libutils.a
libutils_a_SOURCES = A.h A.cpp B.h B.cpp
noinst_HEADERS = A.h B.h
libutils_a_LIBADD = $(top_builddir)/project/utils/console/libconsole.a\
- ---
and
- --- Makefile.am of project/main
noinst_LIBRARIES = libmain.a
libmain_a_SOURCES = A.h A.cpp B.h B.cpp
libmain_a_LIBADD =
noinst_PROGRAMS = project
project_SOURCES = main.cpp
project_LDADD = $(top_builddir)/project/main/libmain.a \
$(top_builddir)/project/utils/libutils.a \
$(top_builddir)/project/gfx/libgfx.a \
$(top_builddir)/project/main \
-lm -lpthread
- ---
As you can see, the helper-lib libconsole.a is no longer listed in
project_LDADD.
This is just an easy example and with such simple project-structures I
never have had any problems. But now it seems quite impossible to get
the helper-lib cross-references for this rather huge right.
I thought if the approach mentioned in the paper "Recursive make
considered harmful" [1] might be a possible solution, which is also to
be found in the automake manual as an alternative to subdirectories [2].
Is there something wrong with my approach here, or is automake simply
not able to resolve these library interdependencies?
Best regards,
Christian
[1]http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html
[2]http://www.gnu.org/software/automake/manual/html_node/Alternative.html#Alternative
- --
Christian Nolte
mailto:address@hidden or mailto:address@hidden
key : http://public.fh-wolfenbuettel.de/~noltec/christian-nolte.asc
or : www.keyserver.net
GPG-fingerprint:
1088 6C2D 1496 0A34 D159 1108 08D8 C0D2 77E1 5BBC
- ----------------------------------------------------------------------
The Information Revolution will be fought on the command line.
- ----------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFDeehsCNjA0nfhW7wRAm3JAKCGPoMLl69mIsoydAvXe4MJr3SvDgCeMYwt
5N72LJaaXEiOQRDL26x9NEs=
=7Dsz
-----END PGP SIGNATURE-----
- automatic linker dependencies for helper-libs to solve undefined references?,
Christian Nolte <=