This topic is 3806 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Dear all: Here is my project structure ./ ./libmesh/ (.a library) ./libvoxel/ (.a library) ./watermark/ (.a library) ./applications/ The Makefile.am in applications looks like:
AM_CPPFLAGS = -I./../libmesh -I/usr/local/include/lapackpp -I./../libvoxel -I../watermark

LIBS = -L../libmesh -lmesh -L../libvoxel -lvoxel -L/usr/local/lib -llapackpp -L../watermark -lwatermark
CPPFLAGS = -Wno-deprecated

noinst_PROGRAMS = pm
pm_SOURCES = pm.cpp


But if a function defined in watermark and it calls the function defined in libmesh and libvoxel, then the compiler complains that the function can't be found.

undefined reference to somefunction<>


And the function is either defined in libmesh or libvoxel. I can build small applications in ./watemark ./libmesh to test their own libraries individually. It seems that the executable program doesn't linked with the static library. Another thing I need to point out that, if I build a static library pm.a, it works fine. Can anyone help me with this question please? Thanks [Edited by - Asuralm on March 18, 2008 11:07:41 AM]

##### Share on other sites
I think it should be:

AM_CPPFLAGS = -Wno-deprecated -I./../libmesh -I/usr/local/include/lapackpp -I./../libvoxel -I../watermark

AM_LDFLAGS = -L../libmesh -L../libvoxel -L/usr/local/lib -L../watermark

AM_LDADD = -lmesh -lvoxel -llapackpp -lwatermark

noinst_PROGRAMS = pm
pm_SOURCES = pm.cpp

OR use the program specific pm_LDFLAGS and pm_LDADD, could be LDLIBS rather tan LDADD.

##### Share on other sites
Quote:
 Original post by AsuralmBut if a function defined in watermark and it calls the function defined in libmesh and libvoxel, then the compiler complains that the function can't be found.*** Source Snippet Removed ***And the function is either defined in libmesh or libvoxel.

With most linkers, the order in which static libraries appear in the list is important. If an unresolved symbol is in a library later in the list (towards the right) that would be resolved by a library earlier in the list, it will not be found.

The general rule of thumb fot avoiding this situation is to make your dependencies a directed acyclic graph. Circular dependencies will cause you grief.

If necessary, a library can appear more than once in the list. I suspect that will be your short-term solution until you've resolved your circular dependencies.

--smw

1. 1
2. 2
3. 3
4. 4
frob
13
5. 5

• 16
• 13
• 20
• 12
• 19
• ### Forum Statistics

• Total Topics
632170
• Total Posts
3004550

×