This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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

Created on 2006-05-12 15:32 by goeran, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (9)
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?)
msg380732 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2020-11-11 00:49
Should we close this as out of date or is there anything that can still be done on it?
msg380786 - (view) Author: Göran Uddeborg (goeran) Date: 2020-11-11 18:27
From my view as reporter, it would be fine to close it. We no longer have any HP-UX systems.
History
Date User Action Args
2022-04-11 14:56:17adminsetgithub: 43352
2020-11-11 18:36:00iritkatrielsetstatus: open -> closed
resolution: out of date
stage: test needed -> resolved
2020-11-11 18:27:35goeransetstatus: pending -> open

messages: + msg380786
2020-11-11 00:49:17iritkatrielsetstatus: open -> pending
nosy: + iritkatriel
messages: + msg380732

2014-02-03 19:16:22BreamoreBoysetnosy: - BreamoreBoy
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