[Python-Dev] can't build with threads on OSF/1

[Thomas Wouters]

--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Oct 13, 2000 at 01:31:34PM -0500, Charles G Waldman wrote:
> Thomas Wouters writes:
>  > 
>  > That's a former DEC alpha, right ? Perhaps running configure with
>  > '--with-dec-threads' will solve the problem ? I'm not sure if that will work
>  > alone, so you might need '--with-dec-threads --with-threads=no' to disable
>  > 'normal' thread-checking. 

> Thank you, that indeed solves the problem.  Sorry for the noise.

No problem. When I went over the README file a few weeks back, and sent
Guido an update, this particular issue was one of the biggest problems for
me: the old README, which assumed threads were not default, was quite
adamant about using --with-dec-threads for OSF/1 and its incarnations.
Unfortunately, it doesn't say why :) And the configure script only says that
it's necessary to get threadsafe libraries.

> It would be nice if configure were smart enough to figure this out!

Configure is as smart as we make it. configure is made by autoconf, which is
moderately intelligent, and we just have to add the extra geniality to
configure.in. If the only check we need is 'does this system call itself
OSF1', we can easily add that. See the attached patch (configure.in version
only. Let me know if you need a patched configure as well, I don't know if
OSF systems come with autoconf. It's pretty large, though, and you don't
need to generate configure on the same system as you run it on. Just apply
the configure.in patch, type 'autoconf', and copy the resulting configure
script to your OSF1 machine.)

The question is, is this enough ? Will this detect all the OSF platforms
that need '-threads', and will it only add it to those platforms ? It
wouldn't be particularly nice of configure if it insisted on adding
'-threads' on platforms that don't need it, or worse, break because of it.
For instance, the patch uses 'OSF*', which might be too generic... but
'OSF1' might be too restrictive :-) A better fix would probably be to write
a test program that explicitly uses threads & the -threads arguments, but
that could fail for a large number of reasons, which doesn't mean -threads
isn't needed :P

(Configure is really amusing like that. For instance, if your compile system
is broken, like when you unpacked a new linux kernel source tree in
/usr/src/linux, but forgot to type 'make symlinks', configure will assume
the worst (every check is negative, after all.) If you're lucky, it will
complain because you miss an essential feature... If you're unlucky, it
finishes cleanly, writes the config.cache file, your compile fails, you
figure out the problem, and you keep compiling using the wrong autoconf
'settings'. And re-configuring doesn't fix it, because the config.cache file
is just fine ;)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="dec-thread.patch"

Index: configure.in
===================================================================
RCS file: /cvsroot/python/python/dist/src/configure.in,v
retrieving revision 1.172
diff -c -r1.172 configure.in
*** configure.in	2000/10/12 17:11:38	1.172
--- configure.in	2000/10/13 19:15:11
***************
*** 805,810 ****
--- 805,819 ----
      LIBS="$LIBS -lthread"
      LIBOBJS="$LIBOBJS thread.o"
      USE_THREAD_MODULE=""])
+ 
+     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
+         OSF*) LDLAST=-threads;;
+         esac
+     fi
  fi
  
  # Check for GC support

--jRHKVT23PllUwdXP--