[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 64bit HPUX problems

From: Albert Chin
Subject: Re: 64bit HPUX problems
Date: Tue, 13 Aug 2002 10:43:16 -0500
User-agent: Mutt/1.2.5i

On Tue, Aug 13, 2002 at 04:32:25PM +0100, address@hidden wrote:
> The change to config.guess is to detect whether the compiler is set
> produce 64bit code.  The concensus (I think) is that hppa2.0w
> represents a 64bit OS with 32bit tools where as hppa*64* represents
> a 64bit tool chain.  A design decision was made by myself that
> libtool itself will not  check for the 64bit environment.  Either
> the user will specify it with the --build flag or config.guess will
> detect (if that change is allowed).

'hppa2.0w' represents the architecture. It has nothing to do with

I disagree with using $host or $build to determine whether or not the
user wants a 32-bit or 64-bit build. Solaris 64-bit builds definitely
don't work this way. Ditto for IRIX 64-bit builds.

Why not do it the way AIX does for runtime linking by setting the
appropriate flags if a 64-bit build is requested (using your __LP64__

> As for hardcode_into_libs, these values where taken from the IA64
> values as this is an HPUX ELF system, which is actually much closer
> in behaviour to PA64 behaviour than the 32bit SOM environment.
> However, I'm easy and if anybody comes out with a categorical
> statement either way, I'll go that way.
> It does fix the problem with -R poluting the $deplibs variable.  All
> I need is some pointers to exactly which lines on code I should be
> looking at.

So you want to know where to set hardcode_into_libs? Look at
libtool.m4's hp section:
  hpux9* | hpux10* | hpux11*)
    # Give a soname corresponding to the major version so that refuses to
    # link against other versions.

Just add a case statement in the above so:
    case $host_os in
    hpux10* | hpux11* )

albert chin (address@hidden)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]