Paul Pluzhnikov wrote: First of all, thanks for all the help and for having patience with me.
> Magnus Jonneryd <[EMAIL PROTECTED]> 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) _______________________________________________ Help-gplusplus mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gplusplus
