Re: [Boost-build] Linking problem in HP-UX with aCC

Subject: Re: [Boost-build] Linking problem in HP-UX with aCC
From: Jim Gallagher (jim_at_[hidden])
Date: 2009-05-26 12:58:01

Joao,

Are you linking in other libraries that may have been built with -AP?
-AA is the default on ia64, unless -AP is explicitly supplied. You can
use chatr or ldd to see the dependencies of shared libs.

Jim

> Date: Mon, 25 May 2009 17:10:55 +0100
> From: Jo?o Lu?s Pinto <joaoluispinto_at_[hidden]>
> Subject: [Boost-build] Linking problem in HP-UX with aCC
>
> Hi,
>
> I'm having two linking problems in a project build on a HP-UX machine.
>
> Versions:
>
> Boost.Build V2 (Milestone 12) [shipped with boost 1.39]
> Boost.Jam 03.1.17
>
> aCC: HP C/aC++ B3910B A.06.16 [Nov 26 2007]
>
> HP-UX B.11.23 ia64
>
> It?s a 64 bit multi-threaded project, compiled with
> "address-model=64". Linkage is performed with the folowing options,
> set by boost-build:
>
> aCC -AA -g +DD64 -mt
>
> According to the aCC man page, the -AA option:
>
> "Turns on newly supported ANSI C++ Standard features such as namespace
> std and the new C++ Standard Library. This option also implies -Aa.
> Include paths are changed to include_std and library is libstd_v2."
>
> But I'm getting the following warning:
>
> ld: (Warning) Unsatisfied symbol "istream::do_ipfx(int)" in file
> /usr/lib/hpux64/libstd.so.1
>
> that suggests libstd is being used instead of libstd_v2. Is this
> expected? Is there a way to explicitely set the version of the stdlib
> used, or do I have to "hammer in" the include path and the correct
> library version using linker flags override?
>
> Also, while compiling a component that links to a library built inside
> the same project, it is complaining that it cannot find that library,
> even though several other executables of the project link with it
> without any problems (in fact all other executables except a
> particular one). The set of libraries is defined by an alias on the
> Jamroot file. Any idea of what could be happening (I thought it might
> be a problem related to the linker input line max size being overrun,
> but I tried compilation with --abbreviate-paths with the same result).
>
> Thank you,
>
> Jo?o
>
>