Build of extension module depending on external lib fails on Solaris 10

Graham Dumpleton Graham.Dumpleton at gmail.com
Fri Nov 21 17:33:48 EST 2008


On Nov 22, 2:07 am, "Eric Brunel" <see.signat... at no.spam> wrote:
> Hello all,
>
> I've got a brand new Solaris 10 computer and I'm trying to build Python  
> and extension modules for it. The Python build didn't have any problem and  
> I have a working Python interpreter. But I can't succeed to build  
> extension modules depending on external libraries: The compilation works,  
> and object files are produced, but the link always fails.
>
> Here is an example of a failing setup.py file:
> ----------------------------------------
>  from distutils.core import setup, Extension
>
> setup(
>    name='spam',
>    version='1.0',
>    ext_modules=[
>      Extension('spam', ['spam.c'], library_dirs=['.'], libraries=['spam'])
>    ]
> )
> ----------------------------------------
>
> The 'spam' external module is basically a copy of the one appearing in the  
> 'Extending and Embedding' manual, except it also contains a call to a  
> function in libspam.a, which just does a printf.
>
> Here is the result of the command 'python setup.py build':
> ----------------------------------------
> running build
> running build_ext
> building 'spam' extension
> gcc -shared build/temp.solaris-2.10-i86pc-2.6/spam.o -L. -lspam -o  
> build/lib.solaris-2.10-i86pc-2.6/spam.so
> Text relocation remains                         referenced
>      against symbol                  offset      in file
> <unknown>                           0xa         ./libspam.a(spamlib.o)
> printf                              0xf         ./libspam.a(spamlib.o)
> ld: fatal: relocations remain against allocatable but non-writable sections
> collect2: ld returned 1 exit status
> error: command 'gcc' failed with exit status 1
> ----------------------------------------
>
> It seems the problem lies in the order on which the object files and  
> libraries appear in the link command line, because if I run the same  
> command with the libraries before the object files:
> gcc -shared -L. -lspam build/temp.solaris-2.10-i86pc-2.6/spam.o -o  
> build/lib.solaris-2.10-i86pc-2.6/spam.so
> the link works without problem and a working shared object file is  
> produced.
>
> Did anybody have this kind of problem? Is it a bug, or am I doing  
> something wrong? And is there a workaround?

See workaround in:

  http://code.google.com/p/modwsgi/wiki/InstallationOnSolaris

Different package, but same issue, so use same workaround.

Graham

Graham




More information about the Python-list mailing list