Python-2.1.1 and gcc-3.0.x ?

P. Alejandro Lopez-Valencia dradul at
Mon Sep 24 13:56:21 CEST 2001

In article <slrn9p9n65.20v.pekko at>, pekko at says...
>I'm having problems when compiling the Python-2.1.1 with gcc-3.0 or
>gcc-3.0.1.  The compiled interpreter seems to run OK, but whenever I'm
>trying to import a module, it complains as:
>Traceback (most recent call last):
>  File "./Lib/test/", line 39, in ?
>    import random
>  File "/scratch/src/Python-2.1.1/Lib/", line 76, in ?
>    from math import log as _log, exp as _exp, pi as _pi, e as _e
>ImportError: /scratch/src/Python-2.1.1/Modules/ undefined symbol:
> __dso_handle
>(This output is from 'make test', that's why the directories are
> under /scratch/src/Python-2.1.1)
>The symbol __dso_handle is defined in the library
>/usr/local/lib/, as you see:
>$ nm -s /usr/local/lib/ | grep __dso_handle
>0000700c d __dso_handle
>Any ideas where to look from advise, or what to do?

I just saw this post, it doesn't talk too well about my keeping up with 
usenet :)

I had the same problem a couple of weeks back under Solaris 2.6. The 
problem is that gcc 3.x uses a different scheme for runtime library 
support, including its own runtime libraries. lib_gcc is a shared library 
in systems that support it. That library is placed in /usr/local/lib 
instead of the private gcc directories under /usr/local/gcc-3 (or 

The practical implication is that you need to harcode all dynamic library 
search paths! In the case of Solaris, it means that all library 
directories (except /lib, the default search path) must be explicitly 
passed to the linker with -R flags both in the main Pytohn linker flags 
and in the module library linker flags. Or use -rpath commands to gcc. If 
you are using Linux, you may be able to declared them globally using 
ldconfig instead.

Alejandro Lopez-Valencia

Kenkon Itteki       ---       Heaven and Earth at one stroke

More information about the Python-list mailing list