Re: Bizarre linkage problem involving archives

[Jo]

Actually, funny thing, it turns out it wasn't a problem of archives
and stuff, it was the order I specified the files. When I did my
tests, I had the parameters_project.o object at the end of the call to
g++. So when I'moved the archive libcommon.a to the end of the g++
call, the problem went way.
   I'm very suprised by this, though. I thought that when a reference
is found, the linker looks at all the defined symbols everywhere
(whether they be in object files, archives or whatever) and gives up
only if the definition is no where. In this case, it seems to find a
reference in the middle of the command-line, and searchs forward on
the command-line for the definition.
  I'm getting this problem all the time now, and changing the order of
things doesn't seem to be helping.

Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> wrote in message 
news:<m3isf38z1s.fsf@salmon.parasoft.com>...
> JoJoTwilligo@hotmail.com (Jo) writes:
> 
> > So shouldn't ../common/libcommon.a be just as good
> > ../common/parameters_project.o?
> 
> Yes, it should.
> 
> To diagnose this further
> 
> - first verify that the file in ../common/libcommon.a is in fact
>   identical to ../common/parameters_project.o:
> 
>    nm ../common/libcommon.a > junk.1
>    nm ../common/parameters_project.o > junk.2
>    diff junk.1 junk.2
> 
> - assuming they are, try this:
> 
>   g++ ... -o executable ../mysql_support/libMySQLsupport.a \
>     ../common/libcommon.a -Wl,-y,g_Log
> 
> The expected output is something like:
> 
> ../mysql_support/libMySQLsupport.a(_sqlsession.o): reference to g_Log
> ../common/libcommon.a(parameters_project.o): definition of g_Log
> 
> You'll probably get different output, which may provide clues.
> 
> Cheers,