[Python-bugs-list] [Bug #113797] Build problems on Reliant Unix
noreply@sourceforge.net
noreply@sourceforge.net
Thu, 12 Oct 2000 09:28:10 -0700
Bug #113797, was updated on 2000-Sep-07 07:33
Here is a current snapshot of the bug.
Project: Python
Category: Build
Status: Open
Resolution: Later
Bug Group: Platform-specific
Priority: 1
Summary: Build problems on Reliant Unix
Details: - 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
Follow-Ups:
Date: 2000-Sep-07 15:05
By: jhylton
Comment:
Please do triage on this bug.
-------------------------------------------------------
Date: 2000-Sep-08 13:45
By: fdrake
Comment:
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?
-------------------------------------------------------
Date: 2000-Sep-12 21:59
By: fdrake
Comment:
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
-------------------------------------------------------
Date: 2000-Sep-15 11:57
By: fdrake
Comment:
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.
-------------------------------------------------------
Date: 2000-Sep-15 13:37
By: fdrake
Comment:
I'm sending a modified version of the configure script to Daniel Dittmar to test for the first two points in this bug report.
-------------------------------------------------------
Date: 2000-Sep-21 08:17
By: fdrake
Comment:
Sent query to Daniel Dittmar asking if he's had a chance to test the revised configure script I sent.
-------------------------------------------------------
Date: 2000-Sep-21 08:46
By: fdrake
Comment:
Received message from Daniel indicating he should get a chace to test the changes this weekend, so it should be available for 2.0b2.
-------------------------------------------------------
Date: 2000-Sep-24 05:46
By: ddittmar
Comment:
- 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
-------------------------------------------------------
Date: 2000-Sep-25 08:10
By: fdrake
Comment:
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.
-------------------------------------------------------
Date: 2000-Sep-28 10:36
By: fdrake
Comment:
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).
-------------------------------------------------------
Date: 2000-Oct-01 09:34
By: ddittmar
Comment:
The patch for the mmap module works on 2.0b2
-------------------------------------------------------
Date: 2000-Oct-01 10:51
By: fdrake
Comment:
mmap patch checked in as Modules/mmapmodule.c revision 2.24.
-------------------------------------------------------
Date: 2000-Oct-02 08:30
By: fdrake
Comment:
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.
-------------------------------------------------------
Date: 2000-Oct-03 09:16
By: fdrake
Comment:
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
-------------------------------------------------------
Date: 2000-Oct-03 09:22
By: fdrake
Comment:
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.
-------------------------------------------------------
Date: 2000-Oct-05 19:00
By: fdrake
Comment:
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.
-------------------------------------------------------
Date: 2000-Oct-12 09:28
By: fdrake
Comment:
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)
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113797&group_id=5470