[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