[Python-bugs-list] [ python-Bugs-691793 ] Python 2.3a2 build fails on Tru64
SourceForge.net
noreply@sourceforge.net
Sun, 23 Feb 2003 16:07:26 -0800
Bugs item #691793, was opened at 2003-02-23 11:46
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=691793&group_id=5470
Category: Build
Group: Python 2.3
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Stephan A. Terre (sfiedler)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Python 2.3a2 build fails on Tru64
Initial Comment:
There is one persistent warning, and then a
build-stopping error, on Tru64.
% uname -a
OSF1 ruby V4.0 1229 alpha
Ran configure to use the vendor compiler as:
env CC=cc CXX=cxx ./configure
--prefix=/var/tmp/sat/python_test
The configuration appeared to go fine. Upon building,
this warning was repeated numerous times:
cc -c -Olimit 1500 -DNDEBUG -O -I. -I./Include
-DPy_BUILD_CORE -o Objects/descrobject.o
Objects/descrobject.c
cc: Info: ./Include/objimpl.h, line 252: In this
declaration, type long double has the same
representation as type double on this platform and is
treated as a synonym for type double in this
compilation mode. (longdoubleny1)
long double dummy; /* force worst-case
alignment */
--------^
And then these errors appeared:
cc -c -Olimit 1500 -DNDEBUG -O -I. -I./Include
-DPy_BUILD_CORE -o Python/thread.o Python/thread.c
cc: Error: /usr/include/sys/psx4_nspace_ts.h, line 147:
Missing type specifier or type qualifier. (missingtype)
ushort entry_cnt; /* Number of
key entries total in the
-------^
cc: Error: /usr/include/sys/psx4_nspace_ts.h, line 149:
Missing type specifier or type qualifier. (missingtype)
ushort entry_size; /* size of key
entry */
-------^
I am happy to try candidate fixes from CVS if that
would be useful.
----------------------------------------------------------------------
>Comment By: Stephan A. Terre (sfiedler)
Date: 2003-02-23 17:07
Message:
Logged In: YES
user_id=246063
I checked the current Python out of CVS. 'configure' worked
fine. Searching config.log for warnings, I find only the
ones about uninitialized variables in test for library
functions, which I believe are fine.
The build succeeded. There was that warning about "long
double" on pretty much every file, and I think perhaps some
other warnings buried in there. I can get a log if you like.
Running the new 'python' produced this warning:
/home/sat/lib/python/startup.py:19: DeprecationWarning:
Non-ASCII character '\xf8' in file
/usr/var/tmp/sat/python/dist/src/Lib/pydoc.py on line 38,
but no encoding declared; see
http://www.python.org/peps/pep-0263.html for details
from pydoc import help
Running "make test" showed a few errors, but I don't know if
these are specific to Tru64 or just part of this release
being "in process". I'm happy to run any of them verbose,
once I figure out how :)
209 tests OK.
5 tests failed:
test_cpickle test_datetime test_format test_pep263
test_xpickle
31 tests skipped:
test_aepack test_al test_audioop test_bsddb test_bsddb3
test_bz2
test_cd test_cl test_curses test_dl test_email_codecs
test_gdbm
test_gl test_iconv_codecs test_imageop test_imgfile
test_linuxaudiodev test_locale test_macfs
test_macostools test_mpz
test_normalization test_ossaudiodev test_pep277 test_rgbimg
test_socket_ssl test_socketserver test_sunaudiodev
test_unicode_file test_winreg test_winsound
Ask someone to teach regrtest.py about which tests are
expected to get skipped on osf1V4.
Note that there were also a couple of similar warnings
during the regression test:
/usr/var/tmp/sat/python/dist/src/Lib/test/test_tarfile.py:6:
DeprecationWarning: Non-ASCII character '\xe4' in file
/usr/var/tmp/sat/python/dist/src/Lib/tarfile.py on line 6,
but no encoding declared; see
http://www.python.org/peps/pep-0263.html for details
import tarfile
The test suite runs twice for some reason, but I don't know
if that's also expected.
I can definitely try the 2.2.2+ version. Just let me know
the tag or how to find the tag for myself. We've been using
2.2.2 since it came out on a variety of Tru64 4.0 and 5.1
machines, without any problems that seem particular to this
platform. So if I haven't seen the bug you're thinking
about, I might not be able to provide good information as to
whether it's fixed. But I can definitely tell you whether
2.2.2+ works for me.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-23 16:38
Message:
Logged In: YES
user_id=33168
Stephan, thanks for your help. Your fixes did seem correct,
although I had already done them, so the fix I checked in
was slightly different. Could you test out the version in
CVS and verify if it corrects your problem? Also, I recall
a bug about OSF1 v4.0 for 2.2.2. These fixes should be
backported, are you able to test the 2.2.2+ version from
CVS? There is a planned release of 2.2.3 soon.
----------------------------------------------------------------------
Comment By: Stephan A. Terre (sfiedler)
Date: 2003-02-23 16:06
Message:
Logged In: YES
user_id=246063
Just realized I was unclear in my previous comment. To test
the fix for _OSF_SOURCE as relates to the test for
"makedev", I altered the file "configure", and rebuilt.
Everything was happy.
The file attached to this bug is the result of changing
"configure.in" along the same lines. However, I do not have
autoconf and so did not regenerate "configure" from
"configure.in". I have *not* tested the patch I'm
submitting, just something which I think is a close
approximation. Although the file is named
"configure_patch.txt", it is really a patch to "configure.in".
I can try to get autoconf working on this system and verify
the patch if you would prefer.
----------------------------------------------------------------------
Comment By: Stephan A. Terre (sfiedler)
Date: 2003-02-23 16:01
Message:
Logged In: YES
user_id=246063
I have verified that everything seems to basically build and
run if I alter the test in configure to put the # at the
first column for preprocessor directives. Attached is a
somewhat more ambitious patch than that: I went through
config.log and found all the places where this seemed to be
happening, and fixed it based on my Very Limited
Understanding of autoconf. I don't have autoconf here to try
this with. So if this is a bad idea, we should solve it some
other way. But hopefully this will work everywhere and will
avoid some other minor problems in the future.
----------------------------------------------------------------------
Comment By: Stephan A. Terre (sfiedler)
Date: 2003-02-23 15:36
Message:
Logged In: YES
user_id=246063
Well, this is rather interesting. The file psx4_nspace_ts.h
is included by <semaphore.h>, which is included by
Python/thread_pthread.h . The type ushort is defined in
<sys/types.h> if the preprocessor symbol _OSF_SOURCE is
defined (which it is not in this case). Here's where it gets
interesting.
It appears that there's an error in <sys/types.h>, because
there's a mismatched #ifdef check for _OSF_SOURCE. I include
the relevant portion below in this message. So it looks like
the intent might actually be to define (via typedef) ushort
merely if _XOPEN_SOURCE_EXTENDED is defined (which it is).
I don't know what the Python policy is for broken system
include files. It may be safe to #define _OSF_SOURCE based
on a configure-time check; however, it appears that
configure.in is presently broken in the way it tries to do
this. Here's the excerpt from config.log that makes me think so:
int
main ()
{
makedev(0, 0)
;
return 0;
}
configure:4807: cc -o conftest -g conftest.c >&5
cc: Warning: configure, line 4787: # not in column 1 is
ignored, skipping to end of line. (ignoretokens)
#define _OSF_SOURCE 1
----^
cc: Warning: configure, line 4788: # not in column 1 is
ignored, skipping to end of line. (ignoretokens)
#include <sys/types.h>
----^
ld:
Unresolved:
makedev
configure:4810: $? = 1
configure: failed program was:
#line 4785 "configure"
#include "confdefs.h"
#define _OSF_SOURCE 1
#include <sys/types.h>
#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern "C"
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
makedev(0, 0)
;
return 0;
}
configure:4833: result: no
As you can see, the Compaq/HP preprocessor does not seem to
accept preprocessor directives unless the # is in the first
column. The result is that the attempt to determine whether
_OSF_SOURCE should be defined for purposes of "makedev"
itself fails. I don't know enough about the configuration
here to know whether fixing this problem would allow the
_OSF_SOURCE symbol to be present. I am going to try changing
pyconfig.h to explicitly define _OSF_SOURCE and see if
everything else still works. I'll post here after I have
done this experiment.
So I guess what I'd like to know from you is whether it's
better to pursue the configure.in problem or to try to add a
specific preprocessor directive somewhere in
thread_pthread.h or thereabouts in order to fix this. Thanks!
Here's the relevant portion of <sys/types.h>. If you try to
match up the #ifdef and the #endif statements, you'll see
that there is apparently a missing #endif somewhere after
the definition of P_MYID. But without knowing the
programmer's intent, it's not clear whether the "corrected"
include file would define ushort in any case.
#if defined(_OSF_SOURCE) || defined(_XOPEN_SOURCE_EXTENDED)
#ifdef _OSF_SOURCE
#ifndef NULL
#define
NULL
0L
#endif
#ifndef TRUE
#define TRUE 1
#endif
#ifndef FALSE
#define FALSE 0
#endif
#ifndef _KERNEL
typedef void (*sig_t) __((int,void (*)(int)));
#else
typedef void (*sig_t) __((int));
#endif
#endif /* _OSF_SOURCE */
/*
* The following type is for various kinds of identifiers. The
* actual type must be the same for all since some system calls
* (such as sigsend) take arguments that may be any of these
* types. The enumeration type idtype_t defined in
sys/procset.h
* is used to indicate what type of id is being specified.
*/
typedef pid_t id_t; /* A process id, */
/* process group id, */
/* session id, */
/* scheduling class id, */
/* user id, or group id.*/
typedef unsigned int useconds_t; /* time in microseconds */
#ifdef _OSF_SOURCE
#define
P_MYID
(-1)
/* a usually illegal value for IDs, but specifying
whatever the value is for my process */
/*
* Types used by dev_t annotation macros (see below)
*/
typedef uint_t major_t; /* major device number */
typedef uint_t minor_t; /* minor device number */
typedef uint_t devs_t; /* device-specific info */
typedef uint_t unit_t; /* unit number of device */
/*
* Basic system types and major/minor device
constructing/busting macros.
*/
#define major(x) ((major_t) (((dev_t)(x)>>20)&07777))
#define minor(x) ((minor_t) ((dev_t)(x)&03777777))
#define makedev(x,y) ((dev_t) (((major_t)(x)<<20) | (minor_t)(y)))
/*
* Disk/Tape (SCSI/CAM - DSA) specific dev_t annotations macros.
*/
#define MAKEMINOR(u,d) ((minor_t) (((unit_t)(u)<<6)
|(devs_t)(d)))
#define GETUNIT(dev) ((unit_t) (minor(dev)>>6)&037777)
#define GETDEVS(dev) ((devs_t) (minor(dev))&077)
#define MAKECAMMINOR(u,d) ((minor_t)
MAKEMINOR((((u&0770)<<5)|((u&07)<<4)),d))
#define GETCAMUNIT(x) ((unit_t)
(((GETUNIT(x))>>5)&0770)|((GETUNIT(x)>>4)&07))
#define GETCAMTARG(x) ((unit_t) ((x >> 3)&07))
#define GETREUNIT(x) ((unit_t) ((x)&07))
#include <mach/machine/vm_types.h>
/*
* shorthand type definitions for unsigned storage classes
*/
typedef
uchar_t
uchar;
typedef
ushort_t
ushort;
typedef
uint_t
uint;
typedef ulong_t ulong;
typedef
physadr_t
physadr;
#ifdef _OSF_SOURCE
/* typedefs for BSD unsigned things */
typedef
uchar_t
u_char;
typedef
ushort_t u_short;
typedef
uint_t
u_int;
typedef
ulong_t
u_long;
typedef
vuchar_t
vu_char;
typedef
vushort_t vu_short;
typedef
vuint_t
vu_int;
typedef
vulong_t
vu_long;
#endif
#ifdef _KERNEL
typedef struct _quad { u_int val[2]; } quad;
#else /* _KERNEL */
typedef struct _quad { int val[2]; } quad;
#endif /* _KERNEL */
typedef
long
swblk_t;
typedef u_long fixpt_t;
#include <sys/select.h>
#endif /* _OSF_SOURCE */
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-23 14:32
Message:
Logged In: YES
user_id=33168
I don't know of any developer that has access to OSF1 v4.0.
Patches would certainly be welcome. :-) The first message
appears to be a warning and seems like it can be ignored.
The two errors from psx4_nspace_ts.h appear to be a problem
with a header file that needs to be included to get the
definition for ushort. If you can attach a patch to this
bug report, I can check on other architectures. Thanks.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=691793&group_id=5470