[Python-bugs-list] [Bug #113037] auotconf/build problems on HP-UX

noreply@sourceforge.net noreply@sourceforge.net
Tue, 29 Aug 2000 09:12:34 -0700


Bug #113037, was updated on 2000-Aug-29 06:57
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: auotconf/build problems on HP-UX

Details: From: Mike Romberg <romberg@fsl.noaa.gov>
To: jeremy@beopen.com
Subject: Fwd: [Bug #111319] Autoconfig breakdown with gnu libc-2.1.3 (noreply@sourceforge.net)
Date: Mon, 28 Aug 2000 11:49:48 -0600 (MDT)

>>>>> " " == Jeremy Hylton <jeremy@beopen.com> writes:

     > Mike, I can't reproduce the bug you report.  Can you check
     > against the current CVS and see if it still has the problem?
     > It may be that the bug has been fixed since you reported it.

  Here is a followup.  Using the CVS tree from last friday, this is
what I get:

  1 - Default install seems to enable threads and cycle-gc.  This has
      core dumps.

  2 - --without-thread.  Dumps core as well.

  3 - --without-cycle-gc --without-thread.  This has some kind of
      problem with the importer.  It breaks with 'from foo import *'.

  4 - I attempted to build this CVS version on HP-UX so that I might
      run purify with it.  The CVS version did not build on HP-UX.
      The build fails with a 'no rule to make dynload-hpux' (or
      something really close).  I removed this object file from the
      Makefile.  But the build failed later on with undeclared
      functions.  I'm still going to try using purify with
      python-1.6b1 (which did compile on HP-UX).

  So, I tried getting a new CVS version this morning.  This core dumps
right off the bat (compiled with --without-cycle-gc --without-thread).

#0  do_mkvalue (p_format=0xbfffe710, p_va=0xbfffe714) at modsupport.c:353
#1  0x869f0c0 in do_mktuple (p_format=0xbfffe710, p_va=0xbfffe714, endchar=41, 
    n=4) at modsupport.c:223
#2  0x869f189 in do_mkvalue (p_format=0xbfffe710, p_va=0xbfffe714)
    at modsupport.c:247
#3  0x869f430 in Py_VaBuildValue (format=0x8a1d8a2 "(OOOO)", va=0xbfffe744)
    at modsupport.c:415
#4  0x869f3c6 in Py_BuildValue (format=0x8a1d8a2 "(OOOO)") at modsupport.c:390
#5  0x868f1f7 in eval_code2 (co=0x8f4c1b8, globals=0x8f4c288, 
    locals=0x8f4c288, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1630
#6  0x868d3b8 in PyEval_EvalCode (co=0x8f4c1b8, globals=0x8f4c288, 
    locals=0x8f4c288) at ceval.c:313
#7  0x869aaaf in PyImport_ExecCodeModuleEx (name=0xbfffe914 "site", 
    co=0x8f4c1b8, pathname=0x8a203ea "<frozen>") at import.c:497
#8  0x869bb82 in PyImport_ImportFrozenModule (name=0xbfffe914 "site")
    at import.c:1387
#9  0x869b869 in load_module (name=0xbfffeda4 "site", fp=0x0, 
    buf=0xbfffe914 "site", type=7) at import.c:1232
#10 0x869c44c in import_submodule (mod=0x8bfe48c, subname=0xbfffeda4 "site", 
    fullname=0xbfffeda4 "site") at import.c:1727
#11 0x869c00d in load_next (mod=0x8bfe48c, altmod=0x8bfe48c, 
    p_name=0xbffff1b0, buf=0xbfffeda4 "site", p_buflen=0xbfffeda0)
    at import.c:1583
#12 0x869bc83 in import_module_ex (name=0x0, globals=0x0, locals=0x0, 
    fromlist=0x0) at import.c:1434
#13 0x869bdbc in PyImport_ImportModuleEx (name=0x8a216c3 "site", globals=0x0, 
    locals=0x0, fromlist=0x0) at import.c:1475
#14 0x869bc20 in PyImport_ImportModule (name=0x8a216c3 "site") at import.c:1408
#15 0x86a014b in initsite () at pythonrun.c:429
#16 0x869fdca in Py_Initialize () at pythonrun.c:166
#17 0x80dbf4c in main (argc=1, argv=0xbffff2d4) at main.C:22



Follow-Ups:

Date: 2000-Aug-29 09:12
By: jhylton

Comment:
More details from comp.lang.python:

From: Philipp Jocham <philipp.jocham@salomon.at>
Subject: Re: need help with build on HP-UX
Newsgroups: comp.lang.python
Date: Tue, 29 Aug 2000 11:23:25 GMT
Message-ID: <N2Nq5.235$HH4.3438@nreader1.kpnqwest.net>

Python-1.6b1 on HP-UX 11.00 build with gcc-2.8.1

% ./configure --with-threads
[...]
checking for --with-thread... yes
checking for mach/cthreads.h... no
checking for pth_init in -lpth... no
checking for pthread_create in -lpthread... no
checking for pthread_detach... no
checking for kernel/OS.h... no
checking for pthread_create in -lpthreads... no
checking for pthread_create in -lc_r... no
checking for __d6_pthread_create in -lthread... no
checking for pthread_create in -lcma... yes
[...]
% make
% make test

yields

[...]
        PYTHONPATH= ./python -tt ./Lib/test/regrtest.py 
pthread_mutex_init: Invalid argument
sh: 5019 Memory fault(coredump)
*** Error exit code 139 (ignored)
	
I've experienced a similar problem with python-1.5.2
see
http://sourceforge.net/bugs/?group_id=5470&func=detailbug&bug_id=110665

The problem is the same. The function pthread_create is a macro
in sys/pthread.h and pointing to __pthread_create_system. Finally
pthread_create is detected in /usr/lib/libcma.a, which doesn't have
a compatible pthread_mutex_init function.

Hacking the Makefiles (after running configure) by changing
the LIBS= lines from
	LIBS=           -lnet -lnsl -ldld  -lcma
to
	LIBS=           -lnet -lnsl -ldld  -lpthread -lcl

links the object-files against the pthread library. 
This solution has worked for 1.5.2 and runs at least all tests
correctly for 1.6b1

A solution might be to add a test for 
	__pthread_create_system in /usr/lib/libpthread.a 
in the configure.in script.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113037&group_id=5470