[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problem using the .a libs ...

From: Kamaljit Singh
Subject: Re: problem using the .a libs ...
Date: Mon, 10 Dec 2007 12:43:00 -0800 (PST)

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 
 in case a later .o leads to an undefined symbol that maybe defined by an 
 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 
     This'll be identical to linking all .o, regardless. Maynot all that 
 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".

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:

elementos = file1.cpp file2.cpp

noinst_LIBRARIES = libDirectoryX.a
libDirectoryX_a_SOURCES =     \


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

In the root directory of my project I have this

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??

Never miss a thing.   Make Yahoo your homepage.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]