classification
Title: Could BIND_FIRST be removed on HP-UX?
Type: behavior Stage: test needed
Components: Interpreter Core Versions: Python 3.2, Python 3.1, Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: BreamoreBoy, Oren_Held, atyutyunnik, goeran, loewis
Priority: normal Keywords:

Created on 2006-05-12 15:32 by goeran, last changed 2011-05-04 19:51 by Oren_Held.

Messages (7)
msg28516 - (view) Author: Göran Uddeborg (goeran) Date: 2006-05-12 15:32
I'm trying to build Python 2.4.3 on HP-UX 11.  I need
tkinter, so I have first built Tcl and Tk 8.4.13.

During the build, the python interpreter crashes.  When
running the setup.py script, just after making the
_tkinter.sl module, it crashes with a memory fault.

I've tried to investigate this, and it seems that
malloc and friends gets confused by the dynamic
loading.  I've filed a support request with HP about this.

One observation I made is that this malloc bug seems to
be connected with the use of BIND_FIRST in
dynload_hpux.c.  If I just remove this flag (in two
places) it appears as if Python works normally.

I'm hesitant if this is a good idea.  BIND_FIRST is
there as an explicit, non-default, flag.  Somebody must
have choosen to do so for some reason.  What was that
reason?  And is it still valid?  If not, maybe the flag
could be removed, and this problem in HP-UX be avoided?
msg28517 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-05-13 16:38
Logged In: YES 
user_id=21627

BIND_FIRST was added with this commit:

------------------------------------------------------------------------
r7068 | guido | 1996-12-06 00:15:35 +0100 (Fr, 06 Dez 1996)
| 2 lines
Geänderte Pfade:
   M /python/trunk/Python/importdl.c

Some extra flags that an HPUX user wants me to add.

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

Guido, do you have any records on which user that was
and why he wanted these flags to be added?
msg28518 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2006-05-18 22:51
Logged In: YES 
user_id=6380

Sorry, I don't have access to email that old any more.

HP-UX is quite different now than it was then.

It would make more sense to ask an HP-UX expert.  I'll ask
Peter Kropf, who helped Elemental with the HP-UX port.
msg28519 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2006-05-19 05:45
Logged In: YES 
user_id=6380

Peter Kropf wrote:

"""
BIND_FIRST causes the dynamic loader to place the newly
loaded shared
library symbol table at the head of the lookup order. This
causes
symbol lookups from that time forward to check the newly
loaded symbol
table before everything else. I can see this causing interesting
things to happen to a program if a shared library contains
symbol
names that are the same as those of, let's say, the C
runtime library.

From what I remember of Python and HP-UX, I'd guess that
this was
added for an extension module. I don't think that it would
be from the
standard Python libraries but rather for a user's custom
extension.
"""
msg28520 - (view) Author: Alexander Tyutyunnik (atyutyunnik) Date: 2007-05-18 23:41
I am using on SWIG 1.3.29+ with Python 2.5 on HP-UX 11.23, Itanium 64bit. It had failed to work (unresolved symbols) until I fixed code this way:
//	flags = BIND_FIRST | BIND_DEFERRED;
	flags = BIND_DEFERRED|BIND_VERBOSE;

instead of:
	flags = BIND_FIRST | BIND_DEFERRED;

Can anyone please fix it?
msg114660 - (view) Author: Mark Lawrence (BreamoreBoy) Date: 2010-08-22 10:16
Is this still valid?
msg114959 - (view) Author: Göran Uddeborg (goeran) Date: 2010-08-26 07:13
Although BIND_FIRST is still there, I could not reproduce the problem with Python 3.1.2.  If it is because something changed in Python, or that HP-UX has fixed something, I don't know.  I still don't see the point in specifying BIND_FIRST here.  But in any case I can not reproduce the problem any more.

(I had to do a couple of tweaks to build on HP-UX 11 with the native compiler.  Is it worthwhile to report them, or is this platform effectively dead from Python's point of view?)
History
Date User Action Args
2011-05-04 19:51:09Oren_Heldsetnosy: + Oren_Held
2010-08-26 07:13:16goeransetmessages: + msg114959
2010-08-22 16:57:58gvanrossumsetnosy: - gvanrossum
2010-08-22 10:16:01BreamoreBoysetnosy: + BreamoreBoy

messages: + msg114660
versions: + Python 3.1, Python 2.7, Python 3.2, - Python 2.6
2009-03-21 02:45:14ajaksu2setstage: test needed
type: behavior
versions: + Python 2.6, - Python 2.4
2006-05-12 15:32:40goerancreate