Re: problem using the .a libs ...

[Kamaljit Singh]

The way the .a work is that if a undefined symbol is defined by a .o in the .a
 then only the .o is linked in otherwise it isnt linked in. But when you do *.o
 then you link in all .o's regardless.
 
 The .o's in the .a are evaluated as they are seen hence they'll not be 
revisited
 in case a later .o leads to an undefined symbol that maybe defined by an 
earlier
 seen .o (from the same .a) but had been deemed to be unimportant and left out.
 
 Some of the following solutions may work for you -
 1. Ensure the correct order in the .a -- maybe erroneous in the long run.
 2. Have the .a twice on the link line - may just work.
 3. You could use -Wl, --whole-archive libxx.a --Wl,--no-whole-archive (for 
linux).
     This'll be identical to linking all .o, regardless. Maynot all that 
portable. 
 4. Have a "-u foo" on the link line so that if some .o defines the symbol "foo"
     it'll always be linked in. For this you'll need to know more about the 
code to
     ensure the "correctness".
 
 kamaljit

Roberto Alejandro Espí Muñoz <address@hidden> wrote: Hi !! I tried building my 
project using the example from the automake
documentation in which i *_LDADD* the static libs in the compilation
process.  My project has about 10 directories and in each one I have
something like this:

directoryX/Makefile.am:
elementos = file1.cpp file2.cpp

noinst_LIBRARIES = libDirectoryX.a
libDirectoryX_a_SOURCES =     \
   $(elementos)

AM_CXXFLAGS = ...
AM_LDFLAGS = ...

Each X is  a number .. directory1, directory2 ... etc ...

In the root directory of my project I have this Makefile.am

link_objects_a = \
    directory1/libDirectory1.a     directory2/libDirectory2.a
directory3/libDirectory3.a ... and so on ...

SUBDIRS = ./directory1 ./directory2 ./directory3 ... and so on ...

bin_PROGRAMS = program

program_SOURCES = main.cpp
program_LDADD =  $(link_objects_a)

program_CXXFLAGS = ......
program_LDFLAGS = .......

I get an error of undefined functions in some of the libDirectoryX.a's with
functions from another libDirectoryX.a.  The funny thing is that it only
happens when I use this notation of *directoryX/libDirectoryX.a *for all my
directories.  If I use the *directoryX/*.o* notation on the libDirectoryX.a's
that give me the problem, the error disappears.

Can anyone tell me if they've had any similar problems?? or none at all??
-- 
teratux
------------
http://teratux.blogspot.com


       
---------------------------------
Never miss a thing.   Make Yahoo your homepage.