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/libstd.sl
ld: (Warning) Unsatisfied symbol "Class tables [Vtable] for type
"bad_alloc"" in file /usr/lib/pa20_64/libstd.sl
ld: (Warning) Unsatisfied symbol "Class tables [Vtable] dependent on key
function: "exception::~exception()"" in file /usr/lib/pa20_64/libstd.sl
ld: (Warning) Unsatisfied symbol "typeid<exception>" in file
/usr/lib/pa20_64/libstd.sl
ld: (Warning) Unsatisfied symbol "exception::~exception()" in file
/usr/lib/pa20_64/libstd.sl
ld: (Warning) Unsatisfied symbol "istream::do_ipfx(int)" in file
/usr/lib/pa20_64/libstd.sl
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/libstd.sl].
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/libstream.sl.
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.
Martin
Travis
