[ python-Bugs-1481770 ] hpux ia64 shared lib ext should be ".so"

[SourceForge.net]

Bugs item #1481770, was opened at 2006-05-04 04:43
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: David Everly (deckrider)
Assigned to: Neal Norwitz (nnorwitz)
Summary: hpux ia64 shared lib ext should be ".so"

Initial Comment:
On hpux ia64, the shared library extension should be
".so".  This is currently problematic in that other
add-on python modules (such as those for subversion)
correctly detect the host_os/host_cpu and build
_module.so, which is not seen by python built using ".sl".

According to
http://devresource.hp.com/drc/resources/portguideipf/index.jsp#dynlinkfac


"Shared library names

Since dynamic linking APIs operate on shared libraries,
it is also important to note that the shared library
naming scheme on Linux is lib*.so; whereas, on HP-UX
11i Version 1.5 the naming scheme is lib*.sl for PA and
lib*.so on IPF. Also APIs may reside in different
libraries files on Linux and HP-UX, so you may need to
dynamically load a different shared library name on
HP-UX and Linux."

To translate this quote, PA=hppa and IPF=ia64.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-10 00:17

Message:
Logged In: YES 
user_id=33168

It looked fine to me too.  I wish you didn't have to set the
extension more than once.  That's not a problem with this
patch though.  I'll try to get around to checking this in
unless someone beats me to it.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2006-05-09 21:50

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me. FYI, we include configure output
in the source repository so that people can build from the
source repository without requiring them to run autoconf
first. Patching configure.in only is the right thing to do;
whoever commits the patch will regenerate configure before
commiting it.

----------------------------------------------------------------------

Comment By: David Everly (deckrider)
Date: 2006-05-08 21:11

Message:
Logged In: YES 
user_id=1113403

I tested against hpux ia64 today, and found that the
original patch required correction.  Here is the result.

----------------------------------------------------------------------

Comment By: David Everly (deckrider)
Date: 2006-05-07 06:22

Message:
Logged In: YES 
user_id=1113403

Here is a patch against
http://svn.python.org/projects/python/branches/release24-maint

I don't have many evironments to test against, and only
Linux right now (will test on HPUX ia64 tomorrow and report
back).

----------------------------------------------------------------------

Comment By: David Everly (deckrider)
Date: 2006-05-05 05:07

Message:
Logged In: YES 
user_id=1113403

The patch I'm using now only works on hppa/ia64 and isn't
anything that can coexist nicely in the source package on
other hardware/os combinations.

I've looked at
http://svn.python.org/projects/python/branches/release24-maint/

I'm accustomed to a system using autoconf/libtool/automake
(recent versions) and never committing the output of those
tools, but only running them at source package generation time.

I say this, only to point out that I'm not understanding the
principles behind what I see in subversion.  I see
configure, and also configure.in.  Which should be patched?
 And if I don't patch configure, what is the process for
regenerating it (and with what versions of automake,
autoconf, and libtool?).

Also, the most recent libtool already correctly determines
shared library extension.

So I could probably provide a patch, but would need to
understand the environment better in order to do so.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-05 00:02

Message:
Logged In: YES 
user_id=33168

Do you think you could work on a patch to address this issue?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&group_id=5470