stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: HP-UX 11.23 aCC 3.73
Date Thu, 07 Feb 2008 00:37:53 GMT
Travis Vitek wrote:
> Travis Vitek wrote:
>> Scott Zhong-2 wrote:
>>> Hi while compiling executables with stdcxx I ran into the following
>>> warnings during linking with +nostl flag:
>>> ld: (Warning) Unsatisfied symbol "ostream::operator <<(const char *)" in
>>> file /usr/lib/pa20_64/
>>> ld: (Warning) Unsatisfied symbol "Class tables [Vtable] for type
>>> "bad_alloc"" in file /usr/lib/pa20_64/
>>> ld: (Warning) Unsatisfied symbol "Class tables [Vtable] dependent on key
>>> function: "exception::~exception()"" in file /usr/lib/pa20_64/
>>> ld: (Warning) Unsatisfied symbol "typeid<exception>" in file
>>> /usr/lib/pa20_64/
>>> ld: (Warning) Unsatisfied symbol "exception::~exception()" in file
>>> /usr/lib/pa20_64/
>>> ld: (Warning) Unsatisfied symbol "istream::do_ipfx(int)" in file
>>> /usr/lib/pa20_64/
>>> after some research, I found that the compile lines needed +nostl as
>>> well to not include the stl that was shipped with HP-UX compiler.  But
>>> doing this I ran into compiler issues such as these:
>> Scott,
>> From my quick look at what you've posted above, it appears that you are
>> overlooking the actual problem.
>> If you look at the original linker error, you'll see that the linker is
>> attempting to link using the native library [/usr/lib/pa20_64/].
>> If you're using +nostl, then you should not be linking to the native
>> library, right?
>> I'd venture to guess that the build would go a little better if it were
>> trying to link to the stdcxx library.
>> Travis
> I think I see where you are going with this. The compile line didn't have
> +nostl, so the native headers were used to compile. I don't see how the
> linker is getting the native library if the +nostl option is used...

He didn't show the link line but I wonder if both libraries have
the same base name, i.e., libstd and maybe the linker is getting
confused. /usr/lib/pa20_64/libstd.s has references to symbols
like istream::do_ipfx that are defined in /usr/lib/

Otherwise, MSVC has a #pragma that, when found in a header, makes
the compiler communicate a dependency on a library to the linker
so that it then knows what library to link the .obj file with just
based on what headers were #included in the object's translation
unit. It's almost like black magic. If HP aCC had the same thing
and Scott's source contained the same #pragma it might explain
why the linker is linking the pre-standard library.


> Travis

View raw message