• Advertisement
Sign in to follow this  

autotools linking problem

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

If you intended to correct an error in the post then please contact us.

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


Link to post
Share on other sites
Advertisement
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 this post


Link to post
Share on other sites
Quote:
Original post by Asuralm
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.
*** 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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement