classification
Title: The Linux2 platform definition is incorrect for alpha, hppa, mips, sparc
Type: behavior Stage: needs patch
Components: Library (Lib) Versions: Python 3.3, Python 3.2, Python 2.7
process
Status: open Resolution:
Dependencies: 12619 Superseder:
Assigned To: Nosy List: doko, eric.araujo, jwilk, loewis, stefanor, ths
Priority: normal Keywords: easy

Created on 2008-09-28 17:23 by ths, last changed 2011-12-21 13:59 by stefanor.

Files
File name Uploaded Description Edit
linux2-plat-upstream.diff ths, 2008-09-28 17:23 Patch for this Bug
Messages (4)
msg73978 - (view) Author: Thiemo Seufer (ths) Date: 2008-09-28 17:23
The linux2 platform definition is incorrect for several architectures,
namely Alpha, PA-RISC(hppa), MIPS and SPARC. On these architectures,
Linux inherited some of the socket and dlfcn constants from the
proprietary OS provided by the hardware manufacturer, which means they
differ from the usual Linux constants.

The appended patch against current SVN adresses this by introducing
linux2-alpha, linux2-hppa, linux2-mips and linux2-sparc platforms.

I changed only the incorrect constants on each platform and kept
everything else the same.

Bugs in the Debian Bugtracker related to this problem are:
http://bugs.debian.org/499132
http://bugs.debian.org/500383
http://bugs.debian.org/500417
http://bugs.debian.org/500418

The first two bug reports carry patches for Python 2.5 and Python 2.4,
respectively.

The patch probably fixes also spurious python segfaults seen on the
Debian Autobuilders for MIPS, since the RTLD_* constants for dlopen were
incorrect. (That said, those segfaults are hard to reproduce, so this is
a somewhat speculative conclusion.)
msg73988 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-09-28 21:01
I dislike the brute-force approach of this patch. IMO, a less intrusive
solution should be found.
msg145836 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-10-18 16:24
If we keep the plat-* directories, I think too that introducing new sys.platform values seems a bit heavy-handed.
msg146840 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-11-02 14:53
A proposal by Martin in a python-dev email:

> I'd generate four versions of CDROM.py (with differing names), and
> provide a CDROM.py that imports the right one.
History
Date User Action Args
2011-12-21 13:59:07stefanorsetnosy: + stefanor
2011-11-02 14:53:48eric.araujosetkeywords: + easy, - patch

messages: + msg146840
stage: needs patch
2011-10-18 16:25:00eric.araujosetnosy: + eric.araujo
dependencies: + Automatically regenerate platform-specific modules
messages: + msg145836
2011-10-18 16:22:07eric.araujosetversions: + Python 3.2, Python 3.3, - Python 2.6, Python 3.1
2010-06-28 11:25:35jwilksetnosy: + jwilk
2010-06-17 01:14:43terry.reedysetversions: - Python 2.5, Python 2.4, Python 3.0
2008-09-28 21:01:53loewissetnosy: + loewis
messages: + msg73988
2008-09-28 17:23:56thscreate