| msg74229 - (view) |
Author: David Jones (drj) * |
Date: 2008-10-03 08:15 |
| Doing a plan "configure" then "make"; the compilation breaks due to // style comments in a file called Objects/frameobject.c: cc_r -qlanglvl=extc89 -c -DNDEBUG -O -I. -IInclude -I./Include - DPy_BUILD_CORE -o Objects/frameobject.o Objects/frameobject.c "Objects/frameobject.c", line 520.9: 1506-046 (S) Syntax error. Full transcript attached. Furthermore, attempting to select a more permissive (better?) compiler, with "CC=c99 ./configure --without-gcc" for example, doesn't work because of the bug reported in http://bugs.python.org/issue1633863 (CC is ignored). I will comment separately in that issue. It is my understanding (per my blog article http://drj11.wordpress.com/2008/10/02/python-and-bragging-about-c89/ ) that the code is now c89 clean (or at least as clean as «gcc -std=c89 - Werror» can make it. That means you should be able to close this bug fairly quickly. :) After I've hacked the configure script the build still fails, but for different reasons. I'll file another bug for that. |
|
|
| msg74232 - (view) |
Author: Georg Brandl (georg.brandl) *  |
Date: 2008-10-03 08:33 |
| Christian, I guess it's all fixed now? |
|
|
| msg76799 - (view) |
Author: Andrew Paprocki (apaprocki) |
Date: 2008-12-02 22:57 |
| summary of compiler errors/warnings i just hit in the same situation with stock Python-2.6.tgz: >>>>>>>>>>>>>> c++ style comment used "Objects/frameobject.c", line 520.9: 1506-046 (S) Syntax error. "Objects/unicodeobject.c", line 118.1: 1506-046 (S) Syntax error. "Objects/unicodeobject.c", line 125.1: 1506-046 (S) Syntax error. "Objects/unicodeobject.c", line 130.1: 1506-046 (S) Syntax error. "Objects/unicodeobject.c", line 149.1: 1506-046 (S) Syntax error. "Objects/unicodeobject.c", line 153.1: 1506-046 (S) Syntax error. & a bunch of other places in unicodeobject.c "Python/_warnings.c", line 380.19: 1506-046 (S) Syntax error. "Python/_warnings.c", line 803.5: 1506-046 (S) Syntax error. >>>>>>>>>>>>>> inline keyword was used "./Modules/signalmodule.c", line 112.1: 1506-277 (S) Syntax error: possible missing ';' or ','? >>>>>>>>>>>>>> other warning "/tmp/Python-2.6/Modules/_ctypes/_ctypes_test.c", line 373.9: 1506-159 (E) Bit field type specified for M is not valid. Type unsigned assumed. "/tmp/Python-2.6/Modules/_ctypes/_ctypes_test.c", line 373.9: 1506-159 (E) Bit field type specified for N is not valid. Type unsigned assumed. "/tmp/Python-2.6/Modules/_ctypes/_ctypes_test.c", line 373.9: 1506-159 (E) Bit field type specified for O is not valid. Type unsigned assumed. "/tmp/Python-2.6/Modules/_ctypes/_ctypes_test.c", line 373.9: 1506-159 (E) Bit field type specified for P is not valid. Type unsigned assumed. "/tmp/Python-2.6/Modules/_ctypes/_ctypes_test.c", line 373.9: 1506-159 (E) Bit field type specified for Q is not valid. Type unsigned assumed. "/tmp/Python-2.6/Modules/_ctypes/_ctypes_test.c", line 373.9: 1506-159 (E) Bit field type specified for R is not valid. Type unsigned assumed. "/tmp/Python-2.6/Modules/_ctypes/_ctypes_test.c", line 373.9: 1506-159 (E) Bit field type specified for S is not valid. Type unsigned assumed. |
|
|
| msg76803 - (view) |
Author: Marc-Andre Lemburg (lemburg) * |
Date: 2008-12-02 23:43 |
| There are still quite a few C99 comments left in the code, esp. in code that's meant for MSVC (which works fine with them) and code for the Mac (which uses gcc and also doesn't have problems with them). Esp. the ctypes and libffi code is full of them. FWIW, this one exists in both SVN trunk and the Python 3.0 branch: ./Modules/_ctypes/callproc.c: -- MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), // Default language Personally, I'd find it a lot better to not use C99 style comments in code that's not specifically meant for a C++-capable compiler like MSVC. |
|
|
| msg76805 - (view) |
Author: Christian Heimes (christian.heimes) * |
Date: 2008-12-03 00:44 |
| Barry, the issue in _ctypes/callproc.c could be a problem for us although Python 2.6 and 3.0 are compiling fine with -std=c89. Should the comment be fixed before the release? |
|
|
| msg76806 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2008-12-03 00:46 |
| For 2.6.1, yes you can fix the comments if you can do it now :) |
|
|
| msg76822 - (view) |
Author: Marc-Andre Lemburg (lemburg) * |
Date: 2008-12-03 10:20 |
| On 2008-12-03 01:44, Christian Heimes wrote: > Christian Heimes <lists@cheimes.de> added the comment: > > Barry, the issue in _ctypes/callproc.c could be a problem for us > although Python 2.6 and 3.0 are compiling fine with -std=c89. Should the > comment be fixed before the release? I had a second look at the code. That comment is in #ifdefs: #ifdef MS_WIN32 ... #endif so it won't affect compiling ctypes on Unix platforms. Still, I find the situation with C99 comments scattered around the source code less than ideal. Either we officially abandon C90 and move on to C99 or we stick to C90 for all source code (including code that only gets compiled on Macs or MSVC). It's just too easy for a C99 comment to slip into code that's targeted for non-gcc/non-MSVC compilers as well and these then break the portability of Python to those compilers/platforms. |
|
|
| msg76833 - (view) |
Author: Andrew Paprocki (apaprocki) |
Date: 2008-12-03 17:22 |
| The list of files/lines I posted yesterday was all that I had to change to get it to build here (where a C++ style comment is a syntax error), so it doesn't seem like a massive change. |
|
|
| msg79342 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2009-01-07 15:42 |
| It seems everything has been fixed in the 2.6 branch and in trunk. Andrew, can you do a quick SVN checkout and test it? |
|
|
| msg104544 - (view) |
Author: Terry J. Reedy (terry.reedy) * |
Date: 2010-04-29 17:48 |
| In the absence of further complaints, this appears to really be fixed. Should it be closed as such? |
|
|
| msg104555 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2010-04-29 18:16 |
| Sure. It can always be reopened if the OP comes back and says it isn't fixed. I'm closing it out of date because there are no references to checkins that fixed it. |
|
|