[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)