hpux ia64 shared lib ext should be ".so"

[deckrider]

BPO	1481770
Nosy	@loewis
Files	hpux-shlib-v2.patch: corrected patch against release24-maint to use correct shared lib ext on hpux

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2006-05-19.07:02:07.000>
created_at = <Date 2006-05-04.11:43:42.000>
labels = ['interpreter-core']
title = 'hpux ia64 shared lib ext should be ".so"'
updated_at = <Date 2006-05-19.07:02:07.000>
user = 'https://bugs.python.org/deckrider'

bugs.python.org fields:

activity = <Date 2006-05-19.07:02:07.000>
actor = 'nnorwitz'
assignee = 'nnorwitz'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2006-05-04.11:43:42.000>
creator = 'deckrider'
dependencies = []
files = ['1991']
hgrepos = []
issue_num = 1481770
keywords = []
message_count = 8.0
messages = ['28415', '28416', '28417', '28418', '28419', '28420', '28421', '28422']
nosy_count = 3.0
nosy_names = ['loewis', 'nnorwitz', 'deckrider']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1481770'
versions = ['Python 2.4']

[deckrider]

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.

[nnorwitz]

Logged In: YES
user_id=33168

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

[deckrider]

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.

[deckrider]

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).

[deckrider]

Logged In: YES
user_id=1113403

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

[loewis]

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.

[nnorwitz]

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.

[nnorwitz]

Logged In: YES
user_id=33168

Thanks! I fixed 2.5. If someone whats to backport to 2.4,
feel free.

Committed revision 46046.