[Python-bugs-list] [Bug #117606] *.so creation in solaris+GCC

noreply@sourceforge.net noreply@sourceforge.net
Fri, 3 Nov 2000 06:32:48 -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.

-------------------------------------------------------

Date: 2000-Nov-03 06:32
By: gward

Comment:
Oops, forgot to mention: the original bug report didn't specify which version of Solaris.  Could be 2.6, 2.7, 2.8, maybe even 2.5, ... 

I have access to 2.6 and 2.7 machines for testing, if it helps.  Have only tried it on 2.6 so far, and that's where it died horribly.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117606&group_id=5470