- the linker requires the options '-W1 -Blargedynsym', otherwise, Python's global functions and variables are not visible to external modules

- when building --with-threads, the linker requires the option -Kpthread

- mmapmodule.o requires a special library

Python version: 2.0b1

compiler version:CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000
CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000

Please do triage on this bug.

We need to know the output of "uname -s" and "uname -r" for this system.  (If "uname -r" reports an error, please try "uname -v".)

Are you willing to test a modified configure script on this platform?

What additional library is required for the mmap module?

Received the following response from Daniel Dittmar <ddittmar@users.sourceforge.net>:

> We need to know the output of "uname -s" and "uname -r" 
> for this system.  (If "uname -r" reports an error, please 
> try "uname -v".)

uname -s
ReliantUNIX-N

uname -r
5.45


> Are you willing to test a modified configure script on
> this platform?

sure.

> What additional library is required for the mmap module?

The man page states -lucb. This didn't work on my machine 
as the BSD compatibility layer is not active. I tell you 
more as soon as I know how to activate it.

***********

Another problem: to detect pthreads, the compiler must be 
called with -Kpthread. Otherwise, pthread.h goes into a 
branch where it tries to include a non existent header, 
fails, and configure reports 'no pthreads'.

Daniel

For the mmap issue, I've added a comment to Modules/Setup.in to let installers know that -lucb may be needed.  In revision 1.110.

I'm sending a modified version of  the configure script to Daniel Dittmar to test for the first two points in this bug report.

Sent query to Daniel Dittmar asking if he's had a chance to test the revised configure script I sent.

Received message from Daniel indicating he should get a chace to test the changes this weekend, so it should be available for 2.0b2.

- configure --without-threads works with the configure patch Revision 1.158

- mmapmodule would work if it includes the lines

#include <unistd.h>

static int
getpagesize (void)
{
    return sysconf (_SC_PAGESIZE);
}

This would be the preferred way as using the BSD compatibility with -lucb is discouraged.

It requires chages to configure (has_pagesize, has_sysconf_sc_pagesize)

- configure --with-threads doesn't build yet, keeping contact with fdrake

Fix to make sure the public API properly exposed to extensions checked in as configure.in revision 1.155.  The rest of these issues can be dealt with in 2.0 final.

I've sent a patch for the mmap module to Daniel to test on Reliant UNIX; the patch should remove the need to link to libucb on that platform (the only platform that needed that as far as we know).

The patch for the mmap module works on 2.0b2

mmap patch checked in as Modules/mmapmodule.c revision 2.24.

Sent another version of the configure script to Daniel Dittmar for testing the thread support.  I think this is the last remaining problem listed in this bug report.

Daniel Dittmar's response:
- the configure script works, except that the correct option is '-Kpthread'
(you mistyped '-Lpthread'

- there's a compilation error in thread_pthread.h:181: the expression
'(long) threadid' is not valid. The definition of pthread_t is 

typedef struct PTHREAD_HANDLE_T {
    void               *field1;
    short int           field2;
    short int           field3;
    } pthread_handle_t;

typedef pthread_handle_t pthread_t;

so I doubt that the alternative 

return (long) *(long *) &threadid

is valid. I could compile it with this version, but I doubt it's returning a
meaningful thread id. Is there a test for the thread module?

I'm away for the rest of the week, so I couldn't test anything for the
Wednesday date.

- for your information, I'm including the results of 'make test', at least
the failed ones:
test test_fork1 crashed -- exceptions.OSError: [Errno 4] Interrupted system
call
test test_popen2 crashed -- exceptions.IOError: [Errno 4] Interrupted system
call
test_signal
Trace/Breakpoint Trap - core dumped
make: *** Error code 133 (ignored)
make: *** Error code 133 (bu21) (ignored)

These test leave a few python processes around.

I'll probably look into this when I return.

Daniel

I've sent a note to Daniel asking for the config.h and config.log files generated by configure.  There's a real problem with the way we're creating thread identifiers; casting to a long just isn't sufficient.

It might be good to know what kind of processor is on the machine.

This won't be resolved for Python 2.0.  There's enough that would be effected by revising the thread identification code that we don't want to destabilize the sources at this point.

We should be able to resolve this for Python 2.1.  I've added a comment about this to the platform notes section of the README file (revision 1.102) to alert the reader to this situation.

I'm recording here part of the needed patch for threads; this is needed in configure.in to get the -Kpthread option passed to the compiler and linker in all the appropriate places.  There are still problems in the code.

(It won't look right in a browser, but it provides all the needed information.)

***************
*** 752,757 ****
--- 752,761 ----
      if test ! -z "$withval" -a -d "$withval"
      then LDFLAGS="$LDFLAGS -L$withval"
      fi
+     case "$ac_sys_system" in
+         ReliantUNIX*) LDFLAGS="$LDFLAGS -Kpthread";
+                       OPT="$OPT -Kpthread";;
+     esac
      AC_DEFINE(_REENTRANT)
      AC_CHECK_HEADER(mach/cthreads.h, [AC_DEFINE(WITH_THREAD)
      AC_DEFINE(C_THREADS)

Logged In: YES 
user_id=3066

Marin, you should be able to close this when you check in
your UnixWare/ReliantUNIX patch.

Logged In: YES 
user_id=21627

With the fix in configure.in 1.231, a -Kpthread binary can
be build on ReliantUnix 5.45 B0032, on RM600 4/512.
Unfortunately, when trying to build the extension modules,
the resulting Python crashes with 
internal error in pthread_mutex_unlock

I have not investigated this further; if the cause of the
problem or a patch is known, please submit an additional bug
report.