[Top][All Lists]

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

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

From: Ross Alexander
Subject: Re: Incorrect library suffix on newer HP-UX (.sl vs .so)
Date: Tue, 07 Oct 2003 23:42:02 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605


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 refuses to
  # link against other versions.
  case "$host_cpu" in

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?


reply via email to

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