[Python-bugs-list] [ python-Bugs-663397 ] Tru64 Unix macro problems
SourceForge.net
noreply@sourceforge.net
Tue, 07 Jan 2003 16:10:28 -0800
Bugs item #663397, was opened at 2003-01-07 00: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: Closed
>Resolution: Invalid
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: Martin v. Löwis (loewis)
Date: 2003-01-08 01:10
Message:
Logged In: YES
user_id=21627
> Is this a documented restriction?
See http://www.python.org/doc/current/api/includes.html (3rd
sentence)
> In practice we've never come across the restriction.
On Linux and Solaris atleast, including Python.h at the
wrong time will give you incorrect definitions for off_t,
and other API that relates to large file support. In one
case, different definitions of off_t have caused an
application crash for the user.
> It is not irrelevant to us.
Then make a bug report providing all necessary details. I
will close this one as invalid.
> What is your prime motivation for manipulating proprietary
> macros directly?
We are not manipulating them, we are defining them -
_OSF_SOURCE is a feature selection macro, the application
defines it to request "interfaces that are proprietary".
The specific feature being requested is the mkdev macro, and
the major and minor macros. They are widely available enough
to expose them from the os module, but DEC considered them
proprietary, and provides _OSF_SOURCE as a mechanism to
access them.
_XOPEN_SOURCE is the primary means for an application to
request that all POSIX functions are available (and
functions take their POSIX meanings if multiple conflicting
meanings are supported on a system). This is known to have
relevant effects on Solaris, Linux, and Tru64; the effects
on Tru64 triggered the definition in Python 2.3.
_POSIX_C_SOURCE must be defined on some system to reacquire
certain interfaces that would have been hidden by defining
_XOPEN_SOURCE. Those aren't proprietary, they are used to
get non-proprietary behaviour across systems.
> Could you please explain why it is necessary to frustrate
users?
It is necessary to define these things to implement features
requested by users, such as large file support, complete
socket libraries, etc. These features now uncover bugs in
user C code that have been there all the time. It is
understandable that users get frustrated, but it is better
if they get compiler error messages instead of mysterious
crashes.
----------------------------------------------------------------------
Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-01-08 00: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 21: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 18: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 13: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