[Python-bugs-list] [Bug #117606] *.so creation in solaris+GCC
noreply@sourceforge.net
noreply@sourceforge.net
Fri, 3 Nov 2000 06:30:05 -0800
Bug #117606, was updated on 2000-Oct-24 08:15
Here is a current snapshot of the bug.
Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: *.so creation in solaris+GCC
Details: Python 2.0 (dinamic modules)
Mod_Python 2.6.2 (dinamic module)
GCC 2.95.2
Apache 1.3.14 (dinamic modules)
SunOS5 (Solaris 2.x)
I send the email also to "mod_python" mailing list since I detect the problem using this package. Other developers could see the very same problem!.
Mod_python runs smoothly until I do a "import zlib", for example, in a handler. In this case, the request is aborted with the following log:
>>>>>
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache: Traceback (most recent call last):
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache: File "/usr/local/lib/python2.0/site-packages/mod_python/apache.py", line 185, in Dispatch
result = object(self.req)
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache: File "/export/home/webmaster/www.argo.es/servicios/cache.py", line 47, in handler
exec(cache[f][1])
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache: File "/export/home/webmaster/www.argo.es/servicios/borra_email", line 183, in ?
req2=wrap(req)
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache: File "/export/home/webmaster/www.argo.es/servicios/borra_email", line 159, in __init__
import zlib
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache: ImportError: ld.so.1: /opt/local/apache/bin/httpd: fatal: relocation error: file /usr/local/lib/python2.0/lib-dynload/zlibmodule.so: symbol main: referenced symbol not found
<<<<<
That is, "zlibmodule.so" tries to link to a function called "main".
Doing a "nm object|grep main", I see the unresolved reference in "zlibmodule.so", but not in "zlibmodule.o". So, the problem seems to be the creation of the shared library.
I tracked down the problem to the "configure" script: "cc -G" is (I think) the right thing to do to create a shared library if you are using the Sun compiler, but if you are using GCC (like me), the right command is "gcc -shared".
Patch for Python 2.0:
>>>>>
Index: configure
===================================================================
RCS file: /opt/src/cvsroot/python/configure,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.2.1
diff -c -r1.1.1.2 -r1.1.1.2.2.1
*** configure 2000/10/18 19:06:44 1.1.1.2
--- configure 2000/10/24 14:19:01 1.1.1.2.2.1
***************
*** 2650,2656 ****
SunOS/4*) LDSHARED="ld";;
SunOS/5*)
if test "$GCC" = "yes"
! then LDSHARED='$(CC) -G'
else LDSHARED="ld -G";
fi ;;
hp*|HP*) LDSHARED="ld -b";;
--- 2650,2656 ----
SunOS/4*) LDSHARED="ld";;
SunOS/5*)
if test "$GCC" = "yes"
! then LDSHARED='$(CC) -shared'
else LDSHARED="ld -G";
fi ;;
hp*|HP*) LDSHARED="ld -b";;
Index: configure.in
===================================================================
RCS file: /opt/src/cvsroot/python/configure.in,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.2.1
diff -c -r1.1.1.2 -r1.1.1.2.2.1
*** configure.in 2000/10/18 19:06:45 1.1.1.2
--- configure.in 2000/10/24 14:19:03 1.1.1.2.2.1
***************
*** 564,570 ****
SunOS/4*) LDSHARED="ld";;
SunOS/5*)
if test "$GCC" = "yes"
! then LDSHARED='$(CC) -G'
else LDSHARED="ld -G";
fi ;;
hp*|HP*) LDSHARED="ld -b";;
--- 564,570 ----
SunOS/4*) LDSHARED="ld";;
SunOS/5*)
if test "$GCC" = "yes"
! then LDSHARED='$(CC) -shared'
else LDSHARED="ld -G";
fi ;;
hp*|HP*) LDSHARED="ld -b";;
<<<<<
Follow-Ups:
Date: 2000-Nov-03 06:30
By: gward
Comment:
I don't think "gcc -shared" is the right answer; at least on Solaris 2.6, with GCC 2.95.2 and Python2.0+ (CVS as of 2000/11/03), compiling extensions dies horribly. The very first extension, arraymodule.c, compiles fine to arraymodule.o. But then linking to arraymodule.so fails with hundreds of symbol relocation errors. About half are "Py" or "_Py" symbols, there are many "<unknown>" (?) symbols, and a handful of errors for 'malloc', 'sprintf', and the like.
I have no idea what's going on here, but "gcc -shared" definitely makes things *worse* for a vanilla (non-embedded) build of Python 2.0+ on Solaris 2.6 with GCC 2.95.2.
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117606&group_id=5470