Re: Incorrect library suffix on newer HP-UX (.sl vs .so)

[Ross Alexander]

Tim,

As the person irresponsible for most of HPUX changes in libtool 1.5 (with
plenty
of help from Dave Anglin and Albert Chin) I have a few comments to make.
Most of the changes where associated with adding ELF-64 support.  This is
very
similar to standard Linux/Solaris ELF.  The entry for that work in dated
2003-01-13
to Albert Chin in the libtool-1.5 ChangeLog.  I still have the patch about
if you'll
really interested.

There are about four places where changes where required in libtool.m4.  In
some
cases it was split into hpux9*, hpux10* etc.  This is mainly because HPUX9
required
at lot more hand holding to create shared libraries.  In other places it
wasn't really
necessary even though it could result in output wasn't strictly true.

Tim Mooney wrote:
> In regard to: Re: Incorrect library suffix on newer HP-UX (.sl vs .so),...:
>
> > Sorry, that was not obvious, I've been thinking you were trying with
> > a later version than that and simply asking for future plans of a
> > feature not visible so far, possibly also browsing into the other cvs
> > files at savannah without finding anything conclusive.
> >
> > Anyway, I've been just looking at the CVS repo at savannah and in the
> > relevant libtool.m4 file, there is the following section that might
> > be helpful to you (it looks good but YMMV):
> >
> > hpux9* | hpux10* | hpux11*)
> >   # Give a soname corresponding to the major version so that dld.sl refuses to
> >   # link against other versions.
> >   version_type=sunos
> >   need_lib_prefix=no
> >   need_version=no
> >   case "$host_cpu" in
> >   ia64*)
> >   
>
> This will likely work, but it's not really correct.
>
> First, there is no ia64* support in 9.x (I'm certain on that) or 10.x (I'm
> 99% certain there).  The stanza for 9.x should probably be pulled off and
> separated from the 10.x and 11.x stanzas, and it could then be simplified
> significantly.  Does anyone remember when 680X0 support ended in HP-UX?
> Was it before 9.x?
In the above case we don't want to split out hpux9 / hpux10 because the SOM
support
would simply end up being duplicated in each case.  That is because it is
the same
for hpux9, hpux10 and hpux11. 
> Second, 9.x and 10.x use `SOM' as the only object file format, and use
> `.sl' as the shared library extension.
> 11.x uses ELF as the default library format (and .so for ELF shared
> libraries), but it can grok older-style SOM libraries.  I don't know
> if the 11.x compiler toolchain can *generate* SOM objects and libraries
> (I suspect it can).  Perhaps someone with access to 11.x (Albert?) can comment.
The above statement is not true.  The 32bit PA-RISC ABI is SOM, irrespective
of
OS release.  HPUX 11i (PA-RISC) certainly still supports SOM.  What changed
in hpux11 is the support for ELF-64 on PA2.0 processors.  But ELF-64 is NOT
the default at all.  Only those programs which really need >4GB memory
use
it.  Basically this is just SAP, Oracle etc.  I added ELF-64 (hppa*64*) support
in
libtool because I wanted to get GNOME to compile 64bit.  SOM has some ugly
behaviour and I wanted to use something nicer (ie ELF64).

> What I don't know for certain is when full 64 bit objects and shared
> libraries started showing up.  I thought there was some minimal support
> in 10.x, but real 64 bit objects and shared libraries weren't available
> until 11.x, in which case the default extension should likely be .so .
No, 64 bit support only came in hpux11.00.  As far as I know, libtool is
colrrect
(atleast 1.5).  For hppa* all shared libraries have the suffix .sl.  All
ia64* shared
libraries are .so (but don't quote me as I don't have access).

The hpux stuff is fairly ugly because there are three supported compilers.
 For SOM
there is only hp's ld so there was only one way to build a shared library,
by calling
ld directly.  In later versions of gcc you could use gcc -shared.  This is
a GOOD THING
because otherwise stuff in libgcc.a could get missed out (linked libgcc.a
to a shared
object is safe because it is compiled -fpic and is therefore relocatable).
 For hppa*64*
things get a bit more complicated because the 64-bit gcc is different executable
(you cannot
get 32bit and 64bit support in the same gcc toolchain).  Also binutils supports
64-bit
linking so you have to check which linker you are using.  I believe it is
recommended
to use hp's linker rather than binutils still because the ELF stuff is broken
in that HP way.

I cannot say about the current status of binutils for ia64 except as far
as I know, only
the hp as/ld are supported at the moment in libtool.  
> Anyone care to comment?
>
> Tim