Repository navigation
Python 2.3a2 build fails on Tru64 #38033
Description
| BPO | 691793 |
|---|---|
| Files |
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']
Activity
sfiedler commentedon Feb 23, 2003
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 commentedon Feb 23, 2003
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 commentedon Feb 23, 2003
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:
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.
typedef
physadr_t
physadr;
typedef
long
swblk_t;
typedef u_long fixpt_t;
#endif /* _OSF_SOURCE */
sfiedler commentedon Feb 23, 2003
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 commentedon Feb 23, 2003
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 commentedon Feb 23, 2003
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 commentedon Feb 24, 2003
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 commentedon Feb 24, 2003
Logged In: YES
user_id=33168
This problem is fixed, so closing bug. Responded to other
issues via email.