This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Python 2.2a4 build problem on HPUX 11.0
Type: Stage:
Components: Build Versions: Python 2.2
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: loewis Nosy List: gvanrossum, loewis, nobody, rptownsend, tim.peters
Priority: normal Keywords:

Created on 2001-10-02 12:10 by rptownsend, last changed 2022-04-10 16:04 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
Test.txt rptownsend, 2001-10-10 09:38 Output from test_descr.py
Gdb.txt rptownsend, 2001-10-11 09:57 Output from gdb.
Make.txt rptownsend, 2001-10-12 08:30 Output from make
Messages (22)
msg6780 - (view) Author: Richard Townsend (rptownsend) Date: 2001-10-02 12:10
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.
msg6781 - (view) Author: Richard Townsend (rptownsend) Date: 2001-10-04 15:10
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.

msg6782 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2001-10-09 10:57
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.
msg6783 - (view) Author: Richard Townsend (rptownsend) Date: 2001-10-09 13:56
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.

msg6784 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2001-10-09 16:41
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".
msg6785 - (view) Author: Richard Townsend (rptownsend) Date: 2001-10-10 09:38
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.

msg6786 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2001-10-10 13:04
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?
msg6787 - (view) Author: Richard Townsend (rptownsend) Date: 2001-10-10 15:06
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...

msg6788 - (view) Author: Richard Townsend (rptownsend) Date: 2001-10-11 09:55
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).

msg6789 - (view) Author: Richard Townsend (rptownsend) Date: 2001-10-11 09:57
Logged In: YES 
user_id=200117

Oops, forgot to check the box...
msg6790 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2001-10-11 10:18
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).
msg6791 - (view) Author: Richard Townsend (rptownsend) Date: 2001-10-11 13:10
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.

msg6792 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2001-10-11 18:33
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
msg6793 - (view) Author: Richard Townsend (rptownsend) Date: 2001-10-12 08:30
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'.

msg6794 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2001-10-12 09:44
Logged In: YES 
user_id=21627

Re-opening; this probably needs to be investigated.
msg6795 - (view) Author: Nobody/Anonymous (nobody) Date: 2001-10-12 11:53
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)
msg6796 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2001-10-12 13:23
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'?
msg6797 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2001-10-12 14:43
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?
msg6798 - (view) Author: Richard Townsend (rptownsend) Date: 2001-10-15 07:28
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.

msg6799 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2001-10-15 19:35
Logged In: YES 
user_id=31435

Reassigned to Guido to match reality.
msg6800 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2001-10-15 19:45
Logged In: YES 
user_id=6380

Thanks! You might want to check current CVS to make sure I
did the right thing.

Is there any reason for this to remain open? Over to MvL for
the answer to that question...
msg6801 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2001-10-16 07:45
Logged In: YES 
user_id=21627

Closing it, since the original problem seems to be solved.

Richard, if any further issues remain, please open a new
report, since it is getting difficult to see in this report
what the problems were and how they got solved.

On the curses issue: Please mail me in private if you want
to pursue creation of a patch. I have some ideas, but cannot
test them due to lack of hardware.
History
Date User Action Args
2022-04-10 16:04:29adminsetgithub: 35263
2001-10-02 12:10:07rptownsendcreate