[Python-bugs-list] [ python-Bugs-663397 ] Tru64 Unix macro problems
SourceForge.net
noreply@sourceforge.net
Tue, 07 Jan 2003 15:46:14 -0800
Bugs item #663397, was opened at 2003-01-06 15:43
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663397&group_id=5470
Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tru64 Unix macro problems
Initial Comment:
Commands used for installing Python 2.3a1:
./configure --prefix=/usr/local_cci/Python-2.3a1
make
make install
Compilation of C++ code (Boost.Python library) fails.
Here is a minimal example:
% cat trouble.cpp
#include <standards.h>
#include <sys/time.h>
#include <Python.h>
% cxx -std strict_ansi -msg_disable 450 -
I/usr/local_cci/Python-2.3a1/include/python2.3 -c
trouble.cpp
cxx: Warning: /usr/local_cci/Python-
2.3a1/include/python2.3/pyconfig.h, line 797:
incompatible redefinition of macro "_OSF_SOURCE"
(declared at line
206 of "/usr/include/standards.h")
#define _OSF_SOURCE 1
--------^
cxx: Warning: /usr/local_cci/Python-
2.3a1/include/python2.3/pyconfig.h, line 804:
incompatible redefinition of
macro "_POSIX_C_SOURCE" (declared at
line 198 of "/usr/include/standards.h")
#define _POSIX_C_SOURCE 200112L
--------^
cxx: Warning: /usr/local_cci/Python-
2.3a1/include/python2.3/pyconfig.h, line 816:
incompatible redefinition of
macro "_XOPEN_SOURCE" (declared at line
188 of "/usr/include/standards.h")
#define _XOPEN_SOURCE 600
--------^
cxx: Error: /usr/include/sys/stat.h, line 204:
identifier "blksize_t" is
undefined
__F64_STAT
--------^
cxx: Error: /usr/include/sys/stat.h, line 204:
identifier "blkcnt_t" is
undefined
__F64_STAT
--------^
cxx: Info: 2 errors detected in the compilation
of "trouble.cpp".
I am glad to open an account on our machine if this could
help in correcting the problem.
Thanks,
Ralf
----------------------------------------------------------------------
>Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-01-07 15:46
Message:
Logged In: YES
user_id=71407
> > The restriction does not exist in Python <= 2.2.
>
> This is not true. It existed in all Python versions. You may
> not have noticed, which might be either because you only got
> silent errors, or because there happened to be no errors on
> your platform.
Is this a documented restriction?
In practice we've never come across the restriction.
We are using Python 2.2 with many versions of gcc under Linux
and Solaris, Visual C++ 6 & 7 and Codewarrior >= 7.2 under
Windows, MipsPro CC under IRIX and Tru64 cxx. Others use
even more
platforms (http://www.boost.org/libs/python/doc/v2/platforms.html).
> > If all libraries took that attitude it would be impossible to
> > combine them.
>
> Irrelevant for the bug in question. There are no other
> libraries.
It is not irrelevant to us. We are using other libraries to create
new Python extensions.
> > The macros in question are not documented in the Tru64 cc
> > and cxx man pages.
>
> _POSIX_C_SOURCE is defined by the POSIX standards.
POSIX
> specifies that applications must define it before including
> system headers. Same for _XOPEN_SOURCE
OK.
> _OSF_SOURCE is defined in standards(5).
The man page does not suggest that defining _OSF_SOURCE is
good or
necessary.
> ... _OSF_SOURCE must be
> defined before any system header is included, or else it
> does not have the desired effect.
_OSF_SOURCE is defined by including <standards.h>. What
difficulties do
you have with this approach? What is your prime motivation for
manipulating proprietary macros directly?
> > The new restriction will frustrate many users of the current
> > Boost 1.29.0 release.
>
> The users will get over their frustration.
I was hoping that we could collaborate on finding a solution
that is good for everybody. Could you please explain why it
is necessary to frustrate users?
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2003-01-07 12:19
Message:
Logged In: YES
user_id=21627
> If all libraries took that attitude it would be impossible to
> combine them.
Irrelevant for the bug in question. There are no other
libraries.
> The macros in question are not documented in the Tru64 cc
> and cxx man pages.
_POSIX_C_SOURCE is defined by the POSIX standards. POSIX
specifies that applications must define it before including
system headers. Same for _XOPEN_SOURCE
_OSF_SOURCE is defined in standards(5).
> The restriction does not exist in Python <= 2.2.
This is not true. It existed in all Python versions. You may
not have noticed, which might be either because you only got
silent errors, or because there happened to be no errors on
your platform.
> The new restriction will frustrate many users of the current
> Boost 1.29.0 release.
The users will get over their frustration.
> It is conceivable that other extension systems are also
> affected negatively.
Not relevant for this bug report.
> #ifdef _OSF // maybe not the right symbol
> # include <some_tru64_header.h>
> #endif
> #ifndef _OSF_SOURCE
> # define _OSF_SOURCE whatever
> #endif
This would be stupid, and incorrect. _OSF_SOURCE must be
defined before any system header is included, or else it
does not have the desired effect.
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-01-07 09:00
Message:
Logged In: YES
user_id=71407
- If all libraries took that attitude it would be impossible to
combine them.
- The macros in question are not documented in the Tru64 cc
and cxx man
pages. Therefore the user should not interfere with these
macros. Even
if the hacks in pyconfig.h work under certain circumstances,
they are
likely to cause complications with future versions of the
compilers.
- The restriction does not exist in Python <= 2.2. Why is it
necessary
to introduce the restriction now?
- The new restriction will frustrate many users of the current Boost
1.29.0 release.
- It is conceivable that other extension systems are also affected
negatively.
All these negative points could easily be eliminated with a more
careful approach like this (pseudocode):
#ifdef _OSF // maybe not the right symbol
# include <some_tru64_header.h>
#endif
#ifndef _OSF_SOURCE
# define _OSF_SOURCE whatever
#endif
...
etc.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2003-01-07 04:59
Message:
Logged In: YES
user_id=21627
That's an error in your code. You must always include
Python.h as the first header file.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663397&group_id=5470