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 17:36:02

One more thing may help: add -Wl,-v to your aCC link command; this
will tell the linker to be verbose, and you should get additional
information about which libs have the problem dependencies.

On Tue, May 26, 2009 at 9:58 AM, Jim Gallagher <jim_at_[hidden]> wrote:
> 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
>>
>>
>