Python 2.3a2 build fails on Tru64

[sfiedler]

BPO	691793
Files	configure_patch.txt: Output of diff -c on configure.in

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2003-02-24.00:52:35.000>
created_at = <Date 2003-02-23.18:46:56.000>
labels = ['build']
title = 'Python 2.3a2 build fails on Tru64'
updated_at = <Date 2003-02-24.00:52:35.000>
user = 'https://bugs.python.org/sfiedler'

bugs.python.org fields:

activity = <Date 2003-02-24.00:52:35.000>
actor = 'nnorwitz'
assignee = 'nnorwitz'
closed = True
closed_date = None
closer = None
components = ['Build']
creation = <Date 2003-02-23.18:46:56.000>
creator = 'sfiedler'
dependencies = []
files = ['800']
hgrepos = []
issue_num = 691793
keywords = []
message_count = 8.0
messages = ['14784', '14785', '14786', '14787', '14788', '14789', '14790', '14791']
nosy_count = 2.0
nosy_names = ['nnorwitz', 'sfiedler']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue691793'
versions = ['Python 2.3']

[sfiedler]

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.

[nnorwitz]

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.

[sfiedler]

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 */

[sfiedler]

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.

[sfiedler]

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.

[nnorwitz]

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.

[sfiedler]

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.

[nnorwitz]

Logged In: YES
user_id=33168

This problem is fixed, so closing bug. Responded to other
issues via email.