[issue4919] 2.6.1 build issues on solaris with SunStudio 12

Changes by Benjamin Peterson : -- resolution: -> out of date status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailin

[issue4919] 2.6.1 build issues on solaris with SunStudio 12

scott wedel added the comment: You all take 7 months to first look at the issue and then decide that you'd like more information because the initial submission was incomplete? Oh well, Suit yourself. Doesn't matter to me. I've already stopped using sunstudio. That python build was one of th

[issue4919] 2.6.1 build issues on solaris with SunStudio 12

Mark Dickinson added the comment: BTW, if there *is* still a problem with building Python 2.6 then closing as 'out of date' wouldn't be appropriate (yet). 2.6 is still receiving bugfixes at this point. -- ___ Python tracker

[issue4919] 2.6.1 build issues on solaris with SunStudio 12

Mark Dickinson added the comment: The original report isn't very useful; without further constructive feedback from the OP I agree this issue should be closed. For example: > The HUGE_VAL aka infinity issue is solved if the LIB is -lsunmath -lm > instead of just -lm What is this mysterious '

[issue4919] 2.6.1 build issues on solaris with SunStudio 12

Mark Lawrence added the comment: I got this in an email from the OP. "Hi, I don't even remember this issue any more, but it seems to me that it is completely irrelevant that the error occurred with software that now how has a newer version. That the essential fact is that the configure proce

[issue4919] 2.6.1 build issues on solaris with SunStudio 12

Mark Lawrence added the comment: Can this be closed as out of date or is it still an issue with Python 2.7 or any of the Python 3 versions? -- nosy: +BreamoreBoy ___ Python tracker

[issue4919] 2.6.1 build issues on solaris with SunStudio 12

New submission from scott wedel : The HUGE_VAL aka infinity issue is solved if the LIB is -lsunmath -lm instead of just -lm Sun Studio 12 compiler also seems to choke on the PyByteArray_GET_SIZE and _AS_STRING because those macros use the ',' operator to stuff an assert before the pointer lookup