[Python-Dev] Problems compiling Python 2.3.3 on Solaris 10 with gcc 3.4.1
Hello, I am having problems compiling Python 2.3.3 on Solaris 10 X86 using gcc 3.4.1. The error message below is generated. I would be grateful for any advice. With friendly regards, Johan Carlstedt # make gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Parser/acceler.o Parser/acceler.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Parser/grammar1.o Parser/grammar1.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Parser/listnode.o Parser/listnode.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Parser/node.o Parser/node.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Parser/parser.o Parser/parser.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Parser/parsetok.o Parser/parsetok.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Parser/bitset.o Parser/bitset.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Parser/metagrammar.o Parser/metagrammar.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Parser/firstsets.o Parser/firstsets.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Parser/grammar.o Parser/grammar.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Parser/pgen.o Parser/pgen.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Parser/myreadline.o Parser/myreadline.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Parser/tokenizer.o Parser/tokenizer.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Objects/abstract.o Objects/abstract.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Objects/boolobject.o Objects/boolobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Objects/bufferobject.o Objects/bufferobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Objects/cellobject.o Objects/cellobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Objects/classobject.o Objects/classobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Objects/cobject.o Objects/cobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Objects/complexobject.o Objects/complexobject.c Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:469: error: invalid operands to binary == Objects/complexobject.c:469: error: wrong type argument to unary minus Objects/complexobject.c:469: error: invalid operands to binary == Objects/complexobject.c:469: error: wrong type argument to unary minus *** Error code 1 make: Fatal error: Command failed for target `Objects/complexobject.o' # gcc --version gcc (GCC) 3.4.1 Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # uname -a SunOS sunbuild1 5.10 s10_71 i86pc i386 i86pc ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems compiling Python 2.3.3 on Solaris 10 with gcc 3.4.1
On Thu, 2004-12-16 at 12:30 +, Johan Carlstedt wrote: > Hello, > > I am having problems compiling Python 2.3.3 on Solaris 10 X86 using gcc > 3.4.1. The error message below is generated. > [SNIP] > Objects/complexobject.c > Objects/complexobject.c: In function `complex_pow': > Objects/complexobject.c:469: error: invalid operands to binary == > Objects/complexobject.c:469: error: wrong type argument to unary minus > Objects/complexobject.c:469: error: invalid operands to binary == > Objects/complexobject.c:469: error: wrong type argument to unary minus Solaris 10 doesn't correctly define HUGE_VAL (I think it's called HUGE in their header files) - so you may want to change the #define in Include/pyport.h from #define Py_HUGE_VAL HUGE_VAL to #define Py_HUGE_VAL HUGE -- Eirik Mikkelsen <[EMAIL PROTECTED]> ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems compiling Python 2.3.3 on Solaris 10 with gcc 3.4.1
If this still occurs with Python 2.3.4 or 2.4, please file a bug so it can be fixed (python-dev isn't a good place to remember fixes). On Thu, 16 Dec 2004 14:03:55 +0100, Eirik Mikkelsen <[EMAIL PROTECTED]> wrote: > On Thu, 2004-12-16 at 12:30 +, Johan Carlstedt wrote: > > Hello, > > > > I am having problems compiling Python 2.3.3 on Solaris 10 X86 using gcc > > 3.4.1. The error message below is generated. > > > [SNIP] > > Objects/complexobject.c > > Objects/complexobject.c: In function `complex_pow': > > Objects/complexobject.c:469: error: invalid operands to binary == > > Objects/complexobject.c:469: error: wrong type argument to unary minus > > Objects/complexobject.c:469: error: invalid operands to binary == > > Objects/complexobject.c:469: error: wrong type argument to unary minus > > Solaris 10 doesn't correctly define HUGE_VAL (I think it's called HUGE > in their header files) - so you may want to change the #define in > Include/pyport.h from > > #define Py_HUGE_VAL HUGE_VAL > > to > > #define Py_HUGE_VAL HUGE > > -- > Eirik Mikkelsen <[EMAIL PROTECTED]> > > ___ > Python-Dev mailing list > [EMAIL PROTECTED] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] re: 2.4 news reaches interesting places
A number of people commented on the article in GCN, at http://gcn.com/vol1_no1/daily-updates/28026-1.html, and wondered if more could not be done to address the perception of speed. The point is made that although people mention all of the benefits of Python, like ease of use, flexibility, they always come back to making references to its speed. And the question is raised, "what can we do to counter this perception?". I think the answer lies in a quote by a user in that same article: "At first, Doak was worried a Python-based program would not run simulations quickly enough, however he found performance to be acceptable. Let's turn this around. Forget about trying to create a perception that Python is fast. Compiled languages will always be faster, at least for large applications. Or at least they'll be perceived that way. So let's acknowledge that upfront, but say "Python is fast enough for most uses", but then go on to say "and in addition to its acceptable speed, it offers many advantages like ease-of-use, flexibility, easy code maintenance (since the code is still understandable 6 months later!) etc. Marketers of other products have used this same technique successfully. For example, at one time there was a perception that Kellogg's Corn Flakes were old and boring. Sales were slipping. Rather than refute that, marketers turned the issue on its head by emphasizing that the product had been around a long time because it was good, and good for you. Hence was born the slogan "taste them again, for the first time". Possible slogan for Python: "Fast enough, and better in many ways". cheers S http://midtoad.homelinux.org/wp/ -- Stewart Midwinter [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] re: 2.4 news reaches interesting places
On Thu, 16 Dec 2004 06:13:41 -0700, Stewart Midwinter <[EMAIL PROTECTED]> wrote: > [...] Possible slogan for Python: "Fast enough, and better in many ways". > [...] Let's make it faster first :-) Cheers, Michael ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: Python in education
On Dec 15, 2004, at 2:58 PM, Terry Reedy wrote: Your primary choice is whether to work on changes in the C code for the interpreter and builtin modules or changes in the Python code in standard library modules. The PyPy folks might be useful too given that they are writing Python in Python. http://codespeak.net/pypy/ -a ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
