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

[SourceForge.net]

Bugs item #1481770, was opened at 2006-05-04 05:43
Message generated for change (Comment added) made by deckrider
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: None
Priority: 5
Submitted By: David Everly (deckrider)
Assigned to: Nobody/Anonymous (nobody)
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: David Everly (deckrider)
Date: 2006-05-05 06: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 01: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