Bugs item #210665, was opened at 2000-07-31 14:12
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210665&group_id=5470
Category: Threads
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Martin v. Löwis (loewis)
Summary: Compiling python on hpux 11.00 with threads (PR#360)
Initial Comment:
Jitterbug-Id: 360
Submitted-By: philipp.jocham@salomon.at
Date: Fri, 16 Jun 2000 08:47:06 -0400 (EDT)
Version: 1.5.2
OS: HP-UX 11.00
There are two missing details in the configure process to make this work
out of the box.
First: The function
pthread_create
isn't found in library libpthread.a but in libcma.a, because
pthread_create is just a macro in sys/pthread.h pointing to
__pthread_create_system
After patching ./configure directly and running
./configure --with-thread
(now detecting the correct library /usr/lib/libpthread.a) I also
added -lcl to Modules/Makefile at
LIBS= -lnet -lnsl -ldld -lpthread -lcl
otherwise importing of modules with threads didn't work
(in this case oci_.sl from DCOracle).
I'm not sure about the correct syntax or wether it's the correct
place and method, but I would suggest a solution like the following
code snippet.
[...]
AC_MSG_CHECKING(for --with-thread)
[...]
AC_DEFINE(_POSIX_THREADS)
LIBS="$LIBS -lpthread -lcl"
LIBOBJS="$LIBOBJS thread.o"], [
AC_CHECK_LIB(pthread, __pthread_create_system, [AC_DEFINE(WITH_THREAD)
[...]
I hope this helps to make installation process smoother.
Fell free to contact me, if there are further questions.
Philipp
--
I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims"). To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.
I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation. I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.
====================================================================
Audit trail:
Tue Jul 11 08:26:01 2000 guido moved from incoming to open
----------------------------------------------------------------------
>Comment By: Martin v. Löwis (loewis)
Date: 2001-10-24 10:20
Message:
Logged In: YES
user_id=21627
According to Richard Townsend, the core of this problem has
been fixed in the CVS. The last related check-in was
configure.in 1.268.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-10-08 06:21
Message:
Logged In: YES
user_id=21627
I have now made the -Kpthread more robust by running a
program; this allows to remove the gcc check (atleast for
Linux and Solaris). The same check should work on all
systems that require special options for pthread support;
please confirm whether it solves the AIX problem.
I've also applied your patch to check pthread_create linkage
through including pthread.h; please report whether
configuration now succeeds on HP/UX.
----------------------------------------------------------------------
Comment By: The Written Word (Albert Chin) (tww-china)
Date: 2001-10-05 10:13
Message:
Logged In: YES
user_id=119770
Well, when -Kpthread was introduced, it should not have
caused a regression on an existing solution. It breaks HP-UX
11.00 (not that it worked before though). And, it will break
AIX. The problem is that:
$ cc foo.c -Kpthread
*will* generate an a.out that is executable. The compiler
just complains about invalid options:
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.
Ditto for the IBM xlc compiler:
$ xlc foo.c -Kpthread
xlc: 1501-210 command option t contains an incorrect subargument
So, the test for -Kpthread has to be more robust.
Regarding AC_CHECK_LIB for pthread_create, the following
will not work:
AC_CHECK_LIB(pthread, pthread_create)
By doing this, you mistakenly assume that pthread_create()
equates to an entry in libpthread named pthread_create. This
is not true on HP-UX 11.00 (nor Tru64 UNIX). The header file
<pthread.h> on HP-UX 11.00 includes <sys/pthread.h> which
has pthread_create() equating to __pthread_create_system. By
using the method I posted, we workaround whatever semantics
the system uses to provide pthread_create.
I will try to work up a solution for -Kpthread. Can I get
access to a UnixWare system to test?
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-10-05 08:21
Message:
Logged In: YES
user_id=21627
I still don't see the breakage on AIX. The compiler will
complain about the option; ok. If the binary is executable
(and really uses threads), what is the problem? In any case,
if you come up with an improved test, I can try it out.
On the pthread_create change: +1. I'd like to see a comment
on why you need to link there, though.
----------------------------------------------------------------------
Comment By: The Written Word (Albert Chin) (tww-china)
Date: 2001-10-04 16:23
Message:
Logged In: YES
user_id=119770
Well, when -Kpthread was introduced, it should not have
caused a regression on an existing solution. It breaks HP-UX
11.00 (not that it worked before though). And, it will break
AIX. The problem is that:
$ cc foo.c -Kpthread
*will* generate an a.out that is executable. The compiler
just complains about invalid options:
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.
Ditto for the IBM xlc compiler:
$ xlc foo.c -Kpthread
xlc: 1501-210 command option t contains an incorrect subargument
So, the test for -Kpthread has to be more robust.
Regarding AC_CHECK_LIB for pthread_create, the following
will not work:
AC_CHECK_LIB(pthread, pthread_create)
By doing this, you mistakenly assume that pthread_create()
equates to an entry in libpthread named pthread_create. This
is not true on HP-UX 11.00 (nor Tru64 UNIX). The header file
<pthread.h> on HP-UX 11.00 includes <sys/pthread.h> which
has pthread_create() equating to __pthread_create_system. By
using the method I posted, we workaround whatever semantics
the system uses to provide pthread_create.
I will try to work up a solution for -Kpthread. Can I get
access to a UnixWare system to test?
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-10-04 16:08
Message:
Logged In: YES
user_id=21627
Just taking out the -Kpthread test is not acceptable. It
will mean that thread support will break systems that
require it. Likewise, taking it as a fallback will fail on
the very same system. Some of those systems (e.g.
UnixWare) do provide a libpthread and a pthread_create
function within, but the documentation explicitly says
that you must not use -lpthread. So we *must* use
-Kpthread were available.
What exactly is the problem on HP/UX? If the compiler
links the test program, why don't threads work then? Can
you give a C program that shows that threads are not
available when just passing -Kpthread? I agree that
special-casing gcc is a hack, but what I need is a
solution, not removal of the existing feature.
Also, what exact problem is solved with your change "for
pthread_create in -lpthread": Why do you need a test
program; why is AC_CHECK_LIB not good enough?
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-04 08:23
Message:
Logged In: YES
user_id=6380
I'm assigning this to Martin, since he checked in the code
that tests for -Kpthread, mentioning Patch #418659: Fixes
for UnixWare and ReliantUnix.
----------------------------------------------------------------------
Comment By: The Written Word (Albert Chin) (tww-china)
Date: 2001-10-03 23:22
Message:
Logged In: YES
user_id=119770
Ok, new patch against HEAD (2.2) at
ftp://ftp.thewrittenword.com/outgoing/pub/python-210665.patch.
BTW, I've axed the addition of determining if "cc -Kpthread"
works. This is gross. Worst case, add it after all of the
other pthread checks. The HP-UX C compiler will link a test
program with -Kpthread. It'll just issue a warning. I see
you've made an exception to setting ac_cv_kpthread if the
compiler is GCC. Ick! The IBM C compiler also issues a
warning about -Kpthread but compiles the test program. The
Sun, Compaq, and SGI compilers do error out though.
With this patch, test_thread succeeds.
----------------------------------------------------------------------
Comment By: The Written Word (Albert Chin) (tww-china)
Date: 2001-08-08 08:11
Message:
Logged In: YES
user_id=119770
I'd rather see a new configure option, --with-cma-threads,
similar to --with-dec-threads, to enable the CMA thread
support for HP-UX 10.20.
We'll try to work on a configure.in patch against CVS for
HP-UX 11.00.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 07:56
Message:
Logged In: YES
user_id=6380
Actually, now that you mention it, yes, there's a reason not
to accept that patch (which I hadn't seen before -- sorry).
It appears to be patching tons of unrelated things, and some
of the diffs in it appear to be diffs between different
Python versions. Also, it patches configure instead of
configure.in. configure is a generated file. Ditto for
config.h.in.
In other words, that patch may fix your problem, but I can't
check it in. Perhaps you could work on a *minimal* patch
that solves the problem, and which works with the current
CVS (or at least the 2.2a1 release). Then I'll look again.
Since you show interest in doing this, I've reopened the bug
report.
----------------------------------------------------------------------
Comment By: Richard Townsend (rptownsend)
Date: 2001-08-08 05:44
Message:
Logged In: YES
user_id=200117
On the 19th June I posted a comment here ref the patch
file: 'python-2.1.patch'
from ftp://ftp.thewrittenword.com/outgoing/pub
After applying this patch to Python 2.1 source, I
successfully built a Python interpreter on HP-UX 11.0 with
threads enabled. (I have tested it with several examples
from Mark Lutz's book using the thread and threading
modules and it works fine).
Is there some reason why you do not accept this patch ?
It would be really useful if this fix could be included for
Python 2.2 :-)
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 12:26
Message:
Logged In: YES
user_id=6380
Closing this for lack of progress.
If someone figures out what to do with threads on HPUX-11,
please submit a fresh *patch*.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-27 10:31
Message:
Logged In: YES
user_id=6380
Alas, not. Those binaries don't have threads enabled.
HP doesn't know how to do it either.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-27 08:37
Message:
Logged In: YES
user_id=6380
For all of those in search for an easy solution:
HP makes binaries available. See
http://hpux.connect.org.uk/hppd/hpux/Languages/python-2.1/
----------------------------------------------------------------------
Comment By: Richard Townsend (rptownsend)
Date: 2001-06-19 03:07
Message:
Logged In: YES
user_id=200117
I have now applied the new patch file 'python-2.1.patch'
available at: ftp://ftp.thewrittenword.com/outgoing/pub
I can now successfully build Python 2.1 with threads
enabled, on HP-UX 11.
----------------------------------------------------------------------
Comment By: Richard Townsend (rptownsend)
Date: 2001-06-14 01:20
Message:
Logged In: YES
user_id=200117
I applied the patch from thewrittenword's site, but when I
ran autoconf it generated a corrupt configure script.
There problem occurs around lines 3895-3906:
if test "$USE_THREAD_MODULE" != "#"
then
# If the above checks didn't disable threads,
(at least) OSF1
# needs this '-threads' argument during linking.
case $ac_sys_system in
OSF1
fi
LDLAST=-threads;;
esac
fi
fi
fi
The case statement has been trashed by the extra 'fi'
token. I tried manually editing it like this:
if test "$USE_THREAD_MODULE" != "#"
then
# If the above checks didn't disable threads,
(at least) OSF1
# needs this '-threads' argument during linking.
case $ac_sys_system in
OSF1) LDLAST=-threads;;
esac
fi
fi
fi
But it still fails with an 'else' not matched at line 3422.
I can't see where the extra 'fi' should go.
----------------------------------------------------------------------
Comment By: The Written Word (Albert Chin) (tww-china)
Date: 2001-05-06 22:36
Message:
Logged In: YES
user_id=119770
You can find a patch to fix this against python 2.1 at:
ftp://ftp.thewrittenword.com/outgoing/pub/python-2.1-416696.patch
You'll need to rerun autoconf to test.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-02 08:38
Message:
Reopened because there's a dissenting opinion.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2000-11-02 07:25
Message:
Ok, check out the configure.in patch I created against Python 2.0:
ftp://ftp.thewrittenword.com/outgoing/pub/python-2.0.patch
I tested it under HP-UX 11.00 and it works just fine. The thread test worked too.
--
albert chin (china@thewrittenword.com)
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2000-11-01 09:18
Message:
Ick! Why check for anything with __ prepended to the name? Isn't that like checking for a "hidden" function, which might not be there in a followup version?
On HP-UX 11.00, pthread_create is in /usr/lib/libc.sl anyway. The proper way to check for pthread_create is:
AC_TRY_LINK([#include <pthread.h>
void * start_routine (void *arg) { exit (0); }], [
pthread_create (NULL, NULL, start_routine, NULL)], [
AC_MSG_RESULT(yes)], [
AC_MSG_RESULT(no)])
I modified configure.in in 2.0 to remove the patch you included in CVS 1.175 and added a test to include <pthread.h> similar to the above (linked without -lpthread and with -lpthread). I'm testing now. Will provide a patch when things are tested.
Also, I don't think threads on HP-UX 10.20 will work unless you have the DCE libraries installed. Anyhow, I'd probably avoid threads on 10.20.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-30 09:48
Message:
Philipp submitted a patch to configure.in that fixes the problem for him and doesn't look like it would break things for others. configure.in, CVS revision 1.175.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-13 07:45
Message:
OK, so the correct thing to do seems to be to somehow add #include <pthread.h> to the tests for thread libraries. I'm afraid I won't be able to fix this in 2.0final, but I'll think about fixing it in 2.1 (or 2.0.1, whichever comes first :-).
----------------------------------------------------------------------
Comment By: Eddy De Greef (edg)
Date: 2000-10-10 04:55
Message:
I can confirm that the bug still exists in 2.0c1.
It works fine on HP-UX 10.20 (which only has libcma),
but not on HP-UX 11 (which both has libcma and libpthread).
The pthread_create function is not defined as a macro though,
but as a static function:
static int pthread_create(pthread_t *tid, const pthread_attr_t *attr, void *(*start_routine)(void *), void *arg)
{ return(__pthread_create_system(tid, attr, start_routine, arg)); }
I don't see an easy way to work around this.
I'm not a configure expert, but perhaps the script should
first check whether this code compiles and links:
#include <pthread.h>
int main()
{
pthread_create(0,0,0,0);
return 0;
}
and if not, fall back on the other tests ?
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-06 10:40
Message:
I have two reports from people for whom configure, build and run with threads now works on HP-UX 10 and 11. I'm not sure what to do about this report... What's different on Philipp's system???
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-25 06:10
Message:
I'm hoping that this was fixed by recent changes. Sent an email to the original submittor to verify.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-22 02:56
Message:
Taking this because I'm considering to redesign the thread configuration section in configure.in anyway -- there's a similar bug report for Alpha OSF1.
----------------------------------------------------------------------
Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-07 15:05
Message:
Please do triage on this bug.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210665&group_id=5470
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4