Re: undefined symbols using StlPort 4.6 and g++ 3.3

[Michael Hunley]

Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> wrote in message 
news:<m3vfiqu320.fsf@salmon.parasoft.com>...
> mhunley@san.rr.com (Michael Hunley) writes:
> 
> > I have also verified that the undefined
> > symbols are in the libstlport_gcc.a located there using nm with
> > --demangle and that they are externed.  
> 
> Now verify that they are *really* there without the --demangle:
> it is often the case that differently-mangled symbols demangle to
> the same name. (You can find out mangled names for the missing
> symbols with e.g. 'nm build/MohoHashtest.o | grep wcerr').
> 
Ok, thanks.  I will do so.

> Was the libstlport_gcc.a compiled with the exact same version of g++?
> Chances are, it wasn't. There have been ABI changes/fixes, which made
> g++-3.0, 3.1, 3.2 and 3.3-compiled code link-incompatible.
> 

Yes.  I built both of them from the same shell to make sure.

I have since tried an experiment where I linked the Solaris generated
.o (and associated libraries from our codebase) on a RedHat9 linux box
with a pre-compiled version of STLPort (.so from open office).  When I
run nm on it I find that the names that are failing, e.g.
_STL::ios_base::Init::Init[in-charge](), actually are decorated with
"[in-charge]" and another is decorated with "[not-in-charge]" on my
linux version.  The version of STLPort I build on solaris, then run nm
on *does not* have these decorators.  Why are they missing from the
emitted symbols when I build STLPort, but included in the unresovled
references when I compile the app source with the same environment?

thanks.
michael

email to mhunley at pokcetpurchase.com