David Kirkby david.kir...@onetel.net added the comment:
Is there any progress on this? I see it is marked as
Status: closed
Resolution: accepted
Stage: patch review
That apparently means:
''There is a patch, but it needs reviewing or is in the process of being
reviewed. This can be
Antoine Pitrou pit...@free.fr added the comment:
As noted by Martin above (he quoted the Subversion revision numbers), this was
actually fixed.
--
resolution: accepted - fixed
stage: patch review - committed/rejected
___
Python tracker
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1759169
___
___
Python-bugs-list mailing
Martin v. Löwis mar...@v.loewis.de added the comment:
Thanks for the patch. Committed as r81582 and r81583.
Antoine was right: subsequent references to Solaris needed to be removed also.
--
resolution: - accepted
status: open - closed
___
Python
Changes by Skip Montanaro s...@pobox.com:
--
nosy: -skip.montanaro
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1759169
___
___
Python-bugs-list
Antoine Pitrou pit...@free.fr added the comment:
A question about the patch: in configure.in, after if test
$define_xopen_source = yes (lines 395 and following), there's a bunch of
Solaris-specific stuff. Shouldn't it be removed, given that _XOPEN_SOURCE isn't
defined anymore under Solaris?
anders musikka anders.musi...@gmail.com added the comment:
Just wanted to chip in my $.02:
Defining _XOPEN_SOURCE in the python headers causes problems for
Solaris. It also causes problems for Ubuntu Linux.
Because _XOPEN_SOURCE is defined, Python.h must included first in any
program under
Zooko O'Whielacronx zo...@zooko.com added the comment:
I just tried to port a library of mine -- zfec -- to Nexenta (the Ubuntu
variant built on top of OpenSolaris). I hit this bug because the
Nexenta folks don't use all the patches that are applied to Python by
the Solaris folks. My port of
Antoine Pitrou pit...@free.fr added the comment:
We're in the middle of a release so this will have to wait until we are
done.
Apart from that, is there a reason *not* to apply the patch?
(it only seems to affect Solaris after all, and Solaris users here seem
consensual that the patch should be
James Andrewartha tr...@ucc.gu.uwa.edu.au added the comment:
I'm jhbuilding GNOME on Solaris, and the attached patch fixes the
problem for me, having compiled Python with it I can now compile
dbus-python, pycairo and pyorbit against it.
--
nosy: +trs80
John Levon movem...@users.sourceforge.net added the comment:
However, experience tells that systems can break in surprising ways
if the system headers are compiled with different defines.
This is indeed a reasonable concern (for which the best solution is
dropping the defines in the Python
Martin v. Löwis mar...@v.loewis.de added the comment:
Python should define *only* __EXTENSIONS__, not the others, as Zooko
already mentioned, for the reasons he mentioned. I'm not sure how you
got a different impression from what I or he said.
Ok, so we can ignore __EXTENSIONS__ for the
Changes by Georg Brandl ge...@python.org:
--
nosy: -georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1759169
___
___
Python-bugs-list
John Levon movem...@users.sourceforge.net added the comment:
Zooko, the patches are available here:
http://src.opensolaris.org/source/xref/jds/spec-files/trunk/patches/
Then you were arguing that defining _XOPEN_SOURCE is wrong if the value
Actually, I was saying that below that value simply
Martin v. Löwis mar...@v.loewis.de added the comment:
Theoretically: yes, it's wrong for Python to claim that all extensions
are compliant to a particular XPG environment.
It's somewhat unfortunate that Python makes such claims for extensions;
primarily, these macros are defined for the
John Levon movem...@users.sourceforge.net added the comment:
Just came across this bug.
_XOPEN_SOURCE_EXTENDED isn't the only sticking point here: neither XPG3
nor XPG4 have C99 either: _XOPEN_SOURCE (at least with a value below
600) is definitely wrong. To quote the header:
346 * It is
Martin v. Löwis mar...@v.loewis.de added the comment:
As Solaris has only ever moved towards the POSIX spec, __EXTENSIONS__ is
the right thing to always specify here
And indeed, Python does define __EXTENSIONS__.
I hope that's a clearer explanation of why Python is doing the wrong
thing
John Levon movem...@users.sourceforge.net added the comment:
Python should define *only* __EXTENSIONS__, not the others, as Zooko
already mentioned, for the reasons he mentioned. I'm not sure how you
got a different impression from what I or he said.
___
Zooko O'Whielacronx zo...@zooko.com added the comment:
Martin (sometimes called MvL) mentioned some specific issues about e.g.
#pragma redefine_extname sigwait __posix_sigwait
I didn't understand exactly what MvL's concern was, and I don't know off
the top of my head how Solaris sigwait
Martin v. Löwis mar...@v.loewis.de added the comment:
If the Sun guy only commented on _XOPEN_SOURCE_EXTENDED, I'm not sure
that this also applies to _XOPEN_SOURCE. For example, on my Solaris 9,
I have (in signal.h) conditionally
#pragma redefine_extname sigwait __posix_sigwait
and in
Zooko O'Whielacronx [EMAIL PROTECTED] added the comment:
Sorry I didn't get back to this ticket, MvL.
Recently someone trying to build the Tahoe distributed filesystem on
Solaris had a problem:
http://allmydata.org/pipermail/tahoe-dev/2008-September/000789.html
They had built Python 2.5
Martin v. Löwis added the comment:
I don't understand the problem. What Solaris version are you using?
Why do you want to remove _XOPEN_SOURCE? Solaris considers this as a
request for XPG 4.2 only _XOPEN_SOURCE_EXTENDED is defined, which it
shouldn't be on Solaris 10.
22 matches
Mail list logo
