[issue1759169] clean up Solaris port and allow C99 extension modules

Antoine Pitrou 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

[issue1759169] clean up Solaris port and allow C99 extension modules

David Kirkby 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 done by any triager as well

[issue1759169] clean up Solaris port and allow C99 extension modules

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue1759169] clean up Solaris port and allow C99 extension modules

Martin v. Löwis 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 tracker

[issue1759169] clean up Solaris port and allow C99 extension modules

Changes by Skip Montanaro : -- nosy: -skip.montanaro ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue1759169] clean up Solaris port and allow C99 extension modules

Antoine Pitrou 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? -- st

[issue1759169] clean up Solaris port and allow C99 extension modules

anders musikka 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 Ubuntu. Perhaps the right

[issue1759169] clean up Solaris port and allow C99 extension modules

Zooko O'Whielacronx 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 my library is blo

[issue1759169] clean up Solaris port and allow C99 extension modules

Antoine Pitrou 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 applied) -

[issue1759169] clean up Solaris port and allow C99 extension modules

Zooko O'Whielacronx added the comment: In msg82274 MvL wrote: "I can grudgingly accept removal of _XOPEN_SOURCE on Solaris 5.{9,10,11} (?), to work-around this system limitation." Great! That's what the attached patch does. So please apply that patch and then people can stop coming to this ti

[issue1759169] clean up Solaris port and allow C99 extension modules

Changes by Skip Montanaro : -- nosy: +skip.montanaro ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue1759169] clean up Solaris port and allow C99 extension modules

Tim Flechtner added the comment: Hi. I think I'm running into the problem discussed in this ticket. I'm trying to build pycairo-1.8.8 on Solaris 10 (x86) against python-2.6.2 using gcc-4.4.1. I'm afraid I'm out of my depth in understanding really what's going on, but the error I get looks lik

[issue1759169] clean up Solaris port and allow C99 extension modules

James Andrewartha 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 ___ Python tracker <

[issue1759169] clean up Solaris port and allow C99 extension modules

John Levon 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 compile). > I do feel this res

[issue1759169] clean up Solaris port and allow C99 extension modules

Martin v. Löwis 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 compilation of Python

[issue1759169] clean up Solaris port and allow C99 extension modules

John Levon 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 won't work for many extension

[issue1759169] clean up Solaris port and allow C99 extension modules

Changes by Georg Brandl : -- nosy: -georg.brandl ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue1759169] clean up Solaris port and allow C99 extension modules

Martin v. Löwis 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 discussion. Then you

[issue1759169] clean up Solaris port and allow C99 extension modules

Zooko O'Whielacronx 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 behavior differs wit

[issue1759169] clean up Solaris port and allow C99 extension modules

John Levon 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. ___ Python tracker

[issue1759169] clean up Solaris port and allow C99 extension modules

Martin v. Löwis 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 both theoreticall

[issue1759169] clean up Solaris port and allow C99 extension modules

John Levon 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 invalid to compile an XPG3, XPG4, X

[issue1759169] clean up Solaris port and allow C99 extension modules

Martin v. Löwis 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 sys/socket.h #pragma rede

[issue1759169] clean up Solaris port and allow C99 extension modules

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 them

[issue1759169] clean up Solaris port and allow C99 extension modules

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