[Python-bugs-list] [ python-Bugs-467145 ] Python 2.2a4 build problem on HPUX 11.0
noreply@sourceforge.net
noreply@sourceforge.net
Mon, 15 Oct 2001 12:35:18 -0700
Bugs item #467145, was opened at 2001-10-02 05:10
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=467145&group_id=5470
Category: Build
Group: Python 2.2
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Richard Townsend (rptownsend)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Python 2.2a4 build problem on HPUX 11.0
Initial Comment:
When compiling Python 2.2a4 on HP-UX 11.0 using the HP
ansi C compiler, each source file generates an error
like this:
cc -Ae -Kpthread -c +DAportable -I. -
I./Include -DHAVE_CONFIG_H -o Parser/acceler.o
Parser/acceler.c
cc: warning 422: Unknown option "K" ignored.
cc: error 1400: Option t usage: -t c,name where c may
be 1 or more of pc0al.
----------------------------------------------------------------------
>Comment By: Tim Peters (tim_one)
Date: 2001-10-15 12:35
Message:
Logged In: YES
user_id=31435
Reassigned to Guido to match reality.
----------------------------------------------------------------------
Comment By: Richard Townsend (rptownsend)
Date: 2001-10-15 00:28
Message:
Logged In: YES
user_id=200117
I made the changes you suggested and most of the warnings
for typeobject.c disappeared.
The other line you mentioned should be changed thus:
3448c3448
< PyObject_GenericGetAttr)
---
> (void *)PyObject_GenericGetAttr)
This fixes all the warnings for that source file.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-12 07:43
Message:
Logged In: YES
user_id=6380
To rptownsend: the warnings you get seem to come from
assigning function pointers to void*. Could you try the
following change?
3693c3693
< {NAME, offsetof(PyTypeObject, SLOT), FUNCTION, WRAPPER}
---
> {NAME, offsetof(PyTypeObject, SLOT), (void *)FUNCTION,
WRAPPER}
3695c3695
< {NAME, offsetof(etype, SLOT), FUNCTION, WRAPPER}
---
> {NAME, offsetof(etype, SLOT), (void *)FUNCTION, WRAPPER}
There's one more line with a warning; can you figure out
where to put a (void*) cast there yourself and let me know?
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-10-12 06:23
Message:
Logged In: YES
user_id=21627
cmkl, a few questions:
- It appears that STRICT_SYSV_CURSES should only be used if
HAVE_NCURSES is not defined. Correct?
- http://devresource.hp.com/STK/partner/xcurses.html claims
that cur_colr is targeted for obsolescence. Why should we
use it then? The same paper claims that
_XOPEN_SOURCE_EXTENDED must be defined on 10.20 if
/usr/include/curses.h (Xcurses) is used, due to a bug.
- What functions does Python use that are only available
with _POSIX_C_SOURCE=199506L ?
- Could you please check out the current CVS and determine
whether Python correctly enables large file support? What is
the problem if only ftello/fseeko are used? What is the
output of 'getconf LFS_CFLAGS'?
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-12 04:53
Message:
Logged In: NO
To use curses (if GPL'd ncurses is not available) you have to make a patch and
you have to compile with:
-DSTRICT_SYSV_CURSES (some ncurses features are not available in this case)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*** ../patch/py_curses.h Fri Dec 22 22:51:10 2000
--- py_curses.h Wed Oct 10 15:06:40 2001
***************
*** 5,11 ****
--- 5,15 ----
#ifdef HAVE_NCURSES_H
#include <ncurses.h>
#else
+ #if defined(__hpux)
+ #include <curses_colr/curses.h>
+ #else
#include <curses.h>
+ #endif
#endif
#ifdef __cplusplus
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To use threads on has to compile with:
-D_POSIX_C_SOURCE=199506L (reentrant fct. are defined then)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To use ftello and fseeko (largefile) one has to compile with:
-D_LARGEFILE_SOURCE
a new largefile API: ftello64 and fseeko64 (instead of ftell64 and fseek64 tested by configure)
is available with:
-D_LARGEFILE64_SOURCE (at the moment there is no difference to -D_LARGEFILE_SOURCE)
/usr/share/doc/lg_files.txt contains the HPUX large file white paper
BTW in Makefile.pre.in if have replaced all occurences of:
$(INSTALL) -d -m
with:
mkdir -p -m
- cmkl (cmkleffner@gmx.de)
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-10-12 02:44
Message:
Logged In: YES
user_id=21627
Re-opening; this probably needs to be investigated.
----------------------------------------------------------------------
Comment By: Richard Townsend (rptownsend)
Date: 2001-10-12 01:30
Message:
Logged In: YES
user_id=200117
I have built from the current CVS and it builds OK
and 'make test' does not produce any failures.
Please note I'm now getting some new warnings for
typeobject.c which I didn't get in Python-2.2a4 - see
attached file 'Make.txt'.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-10-11 11:33
Message:
Logged In: YES
user_id=31435
Reassigned to me and Closed as Fixed, but it would be very
helpful if you could build from current CVS to confirm the
fix on your platform (I'm using a union trick to force the
GC header to have no-looser-than-double alignment, which
should also help on platforms that don't require 8-byte
double alignment but run faster if doubles are 8-byte
aligned).
Include/objimpl.h; new revision: 2.43
Modules/gcmodule.c; new revision: 2.24
----------------------------------------------------------------------
Comment By: Richard Townsend (rptownsend)
Date: 2001-10-11 06:10
Message:
Logged In: YES
user_id=200117
Yes that fixes it, test_descr.py now runs OK.
>From our experiments, I can confirm sizeof(long) == 4 and a
double does require 8-byte alignment on HP-UX 11.00.
I also ran 'make test' again and now get no failures.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-11 03:18
Message:
Logged In: YES
user_id=6380
Thanks. It looks like it's not happy with the alignment of
a pointer to double; in particular, it's in Number.__repr__
in function complexes(). I'm assuming that on your
architecture:
- sizeof(long) == 4
- a double requires 8-byte alignment
Then I believe I have a fix. Can you try this:
In Include/objimpl.h, in the structure PyGC_Head, after "int
gc_refs;" (line 272), insert another -- dummy -- int field,
e.g. "int dummy;".
Then recompile and re-run the test.
If this fixes the problem, I have some work to do, but it
would confirm my theory (that the alignment is botched
because the GC header moves the structure up 12 bytes).
----------------------------------------------------------------------
Comment By: Richard Townsend (rptownsend)
Date: 2001-10-11 02:57
Message:
Logged In: YES
user_id=200117
Oops, forgot to check the box...
----------------------------------------------------------------------
Comment By: Richard Townsend (rptownsend)
Date: 2001-10-11 02:55
Message:
Logged In: YES
user_id=200117
After doing a CVS update, test_descr.py still core dumps.
See attached file Gdb.txt for the output from gdb (hope
it's what you want).
----------------------------------------------------------------------
Comment By: Richard Townsend (rptownsend)
Date: 2001-10-10 08:06
Message:
Logged In: YES
user_id=200117
I will try.
However, there will be a delay as I do not have cvs access
to the internet here at work. I will have to do the update
from home and bring in the new files to build tomorrow :-(
Also, I'm not sure if we have gdb on the HP machines...
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-10 06:04
Message:
Logged In: YES
user_id=6380
Can you do a CVS update and run the test for test_descr.py
again? If it still core dumps, can you provide a stack trace
using gdb?
----------------------------------------------------------------------
Comment By: Richard Townsend (rptownsend)
Date: 2001-10-10 02:38
Message:
Logged In: YES
user_id=200117
Thanks for the pointer.
I have downloaded the current CVS and it builds without the
errors for '-Kpthread'. (It still fails to build the
_curses extension by the way).
When I ran 'make test' it failed in test_descr.py [see
attached file test.txt for output].
I then manually ran the following tests:
test_thread.py
test_threaded_import.py
test_threaded_tempfile.py
test_threading.py
and these all succeeded.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-10-09 09:41
Message:
Logged In: YES
user_id=21627
Please have a look at
http://sourceforge.net/cvs/?group_id=5470
This has instructions for "Anonymous CVS Access".
----------------------------------------------------------------------
Comment By: Richard Townsend (rptownsend)
Date: 2001-10-09 06:56
Message:
Logged In: YES
user_id=200117
I would be happy to try - please can you advise how to
download the current CVS, I can only see the option to
browse it and download individual files.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-10-09 03:57
Message:
Logged In: YES
user_id=21627
Can you please try the current CVS and report whether it
also fixes the problem? The fix you've used was integrated
in a modified form.
----------------------------------------------------------------------
Comment By: Richard Townsend (rptownsend)
Date: 2001-10-04 08:10
Message:
Logged In: YES
user_id=200117
I have now tested the patch
ftp://ftp.thewrittenword.com/outgoing/pub/python-
210665.patch with Python-2.2a4 and it fixes this problem.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=467145&group_id=5470