[Python-bugs-list] [ python-Bugs-693094 ] Python does not build --with-pydebug on Tru64 with vendor cc
SourceForge.net
noreply@sourceforge.net
Mon, 26 May 2003 11:11:43 -0700
Bugs item #693094, was opened at 2003-02-25 11:48
Message generated for change (Comment added) made by sfiedler
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693094&group_id=5470
Category: Build
Group: Platform-specific
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Stephan A. Terre (sfiedler)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Python does not build --with-pydebug on Tru64 with vendor cc
Initial Comment:
The default standards-compliance level for the
Compaq/HP compiler defines the assert macro using the
if statement (if...then) rather than the ternary if
expression (?:). As a result, when Python is configured
--with-pydebug (so NDEBUG is not defined), the macro
Py_SAFE_DOWNCAST expands to illegal C (containing a
statement inside an expression).
This can be fixed by asserting the -std switch to the
vendor compiler. Testing of 2.2.2 CVS and 2.3 CVS
indicates that there is no bad side effect to asserting
-std.
I hope to develop a fix for this in configure.in
sometime in the next couple of days. When I have done
so, I will attach it to this bug.
For the record, here are the variations of the -std
switch on the vendor compiler:
-std0
Selects the K & R language mode. This is the
default. Enforces the K &
R programming style, with certain ANSI extensions
in areas where the K
& R behavior is undefined or ambiguous. In
general, -std0 compiles most
pre-ANSI C programs and produces expected
results. The -std0 option
causes the __STDC__ macro to be undefined.
-std
Selects the relaxed ANSI language mode. Enforces
the ANSI C standard,
but allows some common programming practices
disallowed by the stan-
dard.
This option does not restrict the Tru64 UNIX name
space (for example,
the names defined in system header files). To
restrict that name space
so that only ANSI C reserved names are visible
from the ANSI C header
files, use the _ANSI_C_SOURCE macro. See
standards(5) for more details.
This option causes the macro __STDC_ to be
defined to 0.
-std1
Selects the strict ANSI language mode. Strictly
enforces the ANSI C
standard and all its prohibitions (such as those
that apply to the han-
dling of void types, the definition of lvalues in
expressions, the mix-
ing of integrals and pointers, and the
modification of rvalues).
This option does not restrict the Tru64 UNIX name
space (for example,
the names defined in system header files). To
restrict that name space
so that only ANSI C reserved names are visible
from the ANSI C header
files, use the _ANSI_C_SOURCE macro. See
standards(5) for more details.
This option causes the macro __STDC_ to be
defined to 1. Note that this
option also affects linker-defined symbols. See
ld(1) for more infor-
mation.
This option turns on ANSI aliasing rules
(-ansi_alias option).
----------------------------------------------------------------------
>Comment By: Stephan A. Terre (sfiedler)
Date: 2003-05-26 11:11
Message:
Logged In: YES
user_id=246063
I'll try the fix tomorrow when I am at work and have access to a Tru64
machine.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-26 07:16
Message:
Logged In: YES
user_id=33168
Checked in as:
* configure 1.402
* configure.in 1.413
Please test the current CVS. It was a little different from
the patch here. I think it should work though.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-25 09:46
Message:
Logged In: YES
user_id=33168
This problem has a tentative solution. Please test the
patch in http://python.org/sf/719359
Scroll to the bottom and click Download on the
osf-opts.patch line. Thanks.
----------------------------------------------------------------------
Comment By: Stephan A. Terre (sfiedler)
Date: 2003-02-27 17:58
Message:
Logged In: YES
user_id=246063
Attached to this bug is a patch to configure.in and configure. I
believe pretty much all of the three decisions I made need
review :)
1. I put the -std flag in BASECFLAGS an OSF1-specific case
in the
non-gcc branch. Should there be some other check here that
we're using
the vendor C compiler? If so, can anyone point me at an example?
2. Upon testing, I found that the getpgrp function has a
different
signature when compiled with -std than without. As a result, the
posixmodule didn't build. My solution was to change the
definition of
CC in configure.in to be "$CC $BASECFLAGS $OPT" after the
last change
to OPT and BASECFLAGS. My thinking is that we ought to be
running
feature and behavior tests with the flags that we'll be
using to build
the interpreter. However, if this goes against the spirit or
policy of
autoconf, we should do something else!
3. I happened to notice an XXX about Monterey, so I did a little
investigation and added to the note. Hopefully this is not a
gaffe.
I have tested the changes to configure.in on Tru64 4.0F both
with and
without the --with-pydebug flag to configure. The test suite
behaved
the same in each case as before my mods.
I also tested the changes --with-pydebug on a Red Hat 7
system; they
seemed good there too.
If I should have put this patch in the Patch Manager rather than
attaching to the bug directly, I apologize and promise never
to do it
wrongly again :)
Please let me know by posting a followup here or via email
if there is
anything else I should do for this bug.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693094&group_id=5470