[issue4919] 2.6.1 build issues on solaris with SunStudio 12

2009-01-12 Thread scott wedel 

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.  When I remove the assert portion of
those macros then they compile fine.

The assertions in those macros appear a bit silly because some places
they are used already have prior assertions and I don't see the point of
the macro which appears to be to crash due to an assertion one statement
prior to the null pointer reference causing a crash.

The configure process also appeared to make a few mistakes such as not
finding uid_t because that is in  and not in the presumed
header file.  If configure were to include the standard header files AND
the file that it expects to find the definition then it would be better
at finding what is defined.  I don't know why Sun does that.

--
components: Build
messages: 79654
nosy: taverngeek
severity: normal
status: open
title: 2.6.1 build issues on solaris with SunStudio 12
versions: Python 2.6

___
Python tracker 
<http://bugs.python.org/issue4919>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4919] 2.6.1 build issues on solaris with SunStudio 12

2010-06-26 Thread scott wedel 

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 the last things I did on Solaris
which I had been actively using for 20 years, but some device driver issues
have made it no longer worth the effort.

sdw

On Sat, Jun 26, 2010 at 4:39 AM, Mark Lawrence wrote:

>
> 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 process makes mistakes
> creates a situation in which the includes fail to work properly.  The only
> relevance of Python x.x is that version DEMONSTRATES the error.
>
> The philosophy that the apparent error need not be considered because right
> now it happens to a possibly obsolete version of software just means it will
> happen again.  Presumably, it will be just another hassle for those that
> test compile against sunstudio.  Using that sort of rationale to close
> issues is exactly how to make sunstudio into a piece of crap.
>
> sdw
> "
>
> Could somebody pick this up?
>
> --
>
> ___
> Python tracker 
> <http://bugs.python.org/issue4919>
> ___
>

--
Added file: http://bugs.python.org/file1/unnamed

___
Python tracker 
<http://bugs.python.org/issue4919>
___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 the last things I did on 
Solaris which I had been actively using for 20 years, but some device driver 
issues have made it no longer worth the effort.
sdwOn Sat, Jun 26, 2010 at 4:39 AM, 
Mark Lawrence <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> 
wrote:

Mark Lawrence <mailto:breamore...@yahoo.co.uk";>breamore...@yahoo.co.uk> 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 process makes mistakes creates a 
situation in which the includes fail to work properly.  The only relevance of 
Python x.x is that version DEMONSTRATES the error.

The philosophy that the apparent error need not be considered because right now 
it happens to a possibly obsolete version of software just means it will happen 
again.  Presumably, it will be just another hassle for those that test compile 
against sunstudio.  Using that sort of rationale to close issues is exactly 
how to make sunstudio into a piece of crap.


sdw
"

Could somebody pick this up?

--

___
Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org>
<http://bugs.python.org/issue4919"; 
target="_blank">http://bugs.python.org/issue4919>
___

___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com