help-gplusplus
[Top][All Lists]
Advanced

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

Re: Linking with a static library.


From: Magnus Jonneryd
Subject: Re: Linking with a static library.
Date: 22 Oct 2005 19:23:07 +0200
User-agent: KNode/0.8.2

Paul Pluzhnikov wrote:

First of all, thanks for all the help and for having patience with me.

> Magnus Jonneryd <magnus.jonneryd@ipbolaget.com> writes:
> 
>>> What is the failing link line and what is the *exact* error message?
>>>
>>  
>> g++ ... -o ../simpleGrid .o/simpleGrid.o -lBody ... -lTheatre ...
>> libTheatre.a(Theatre.o)(.text+0x92): In function
>> `Rendering::Theatre::render()':
>> : undefined reference to `Rendering::BodyFactory::render()'
> 
> It is clear from the this message that your problem is *exactly*
> the one of incorrect library ordering (searching Chemistry bookshelf
> before the Biology one) as explained here:
> 
>>>  http://webpages.charter.net/ppluzhnikov/linker.html
>>> 
>>
>> I still can't figure out why I'm able to link if i instantiate an object
>> of class BodyFactory in my main method, if i do that everything seems to
>> work.
> 
> Because in that case the compiler generates code in the main object
> which references BodyFactory, and the librarian dutifully pulls
> BodyFactory.o from the libBody.a because BodyFactory* symbols are
> now on her "needed" list.
> 
> You didn't really read the page I referred you to, did you?
>

I read it, promise (see below).
 
>> It also seems to work if I add the library libBody.a to the
>> linker line, after libTheatre.a, for the life of me I can't figure out
>> why.
> 
> It is *all* explained in that web page. You really ought to read it.
> 
>> I've read what you wrote (linker.html) and i thought i understood it, but
>> apperently not.
> 
> Hmm, what didn't you understand?

Sorry, probably posted to soon. Reread your page and can honestly say that
it proved to be of great help. A necessary read, for me at least, and
something i would recommend to anyone. The analogy you use to describe the
linking should be in a textbook or something.

> 
> Librarian comes to libBody.a, and doesn't pull BodyFactory.o because
> there is nothing in her "needed" list that tells her she needs it.
> 
> She then searches libTheatre.a and pulls Theatre.o because it has been
> referenced somewhere ...
> 
> *Now* she needs BodyFactory* symbols, but since she never re-visits
> libBody.a, she never gets a chance to find definitions for them,
> hence the link error.
> 
>> Something else that really bugs me is that if i use nm to find the
>> symbols in the library i get this:
>>
>> nm -BC libBody.a | grep BodyFactory
>>
>> 76:BodyFactory.o:
>> 92:00000060 T Rendering::BodyFactory::render()
> ...
>> Doesn't this imply that the symbol exists and that i should be able to
>> link to it?
> 
> Yes it does, and yes you should, *provided* you link in correct order!
> 
> Since libTheatre.a refers to symbols in libBody.a, it should
> *preceed* libBody.a on the link line.

This is something I thought about as the other way around. In my muddled
view of the world the librarian extracted all the symbols, but given a
little thought i realize that would generate a symbols table
that is unnecessarily large.

> If libBody.a in turn references symbols from libTheatre.a, then
> you have a badly-structured libraries, and the solution is to
> either merge them into a single archive (this is the most portable
> solution), use --begin-group/--end-group (GNU linker only), or list
> the libraries multiple times.
> 
> All of this is explained in linker.html.
> 
> Cheers,

Thank you, now I can finally get a good night sleep. Have been thinking
about this and it really, really bothered me.


--  
(Should insert humorous quotation here)


reply via email to

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