Re: 64bit HPUX problems

[Albert Chin]

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
HP-UX.

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__
trick)?

> 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 dld.sl refuses to
    # link against other versions.
  ...

Just add a case statement in the above so:
    case $host_os in
    hpux10* | hpux11* )
      hardcode_into_libs=yes
      ;;
    esac

-- 
albert chin (address@hidden)