Linking problem on Linux

Development
1

With current master, I get this on an x86_84 Linux box:

    Linking CXX shared module _SubnetTree.so
    /usr/bin/ld: /local/lib/python2.6/config/libpython2.6.a(abstract.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
    /local/lib/python2.6/config/libpython2.6.a: could not read symbols: Bad value

Any ideas?

Robin

2

That must be some python-specific problem. I haven't had any issues
(yesterday anyway) on Ubuntu 10.04 LTS.

3

I do not see this error. I'm using Ubuntu 10.04.3 (x86_64).

-Daniel

4

Ok, then I'll need to figure out what's wrong with the Python
installation on that machine.

Thanks (also to Martin),

Robin

5

With current master, I get this on an x86_84 Linux box:

   Linking CXX shared module _SubnetTree.so
   /usr/bin/ld: /local/lib/python2.6/config/libpython2.6.a(abstract.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
   /local/lib/python2.6/config/libpython2.6.a: could not read symbols: Bad value

Any ideas?

I think the situation you're in is that you're building a shared library on an AMD64 architecture which are required to be PIC-enabled, but you're linking to a static archive which was not built with the -fPIC flag.

Was this a manual build of python? You might need to configure it to enable shared libraries (or if you really want to just use the static one, you have to configure it with the -fPIC flag).

- Jon

6

+1 this.

Reference: http://stackoverflow.com/questions/629961/how-can-i-set-ccshared-fpic-while-executing-configure

--Gilbert

7

Oh, actually, this may be relevant as well...

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

Under "Mixing 32 Bit And 64 Bit Packages"

[quote] This error is believed to be result of the version of Python being used having been originally compiled for the generic X86 32 bit architecture whereas mod_wsgi is being compiled for X86 64 bit architecture. The actual error arises in this case because 'libtool' would appear to be unable to generate a dynamically loadable module for the X86 64 bit architecture from a X86 32 bit static library. Alternatively, the problem is due to 'libtool' on this platform not being able to create a loadable module from a X86 64 bit static library in all cases.

If the first issue, the only solution to this problem is to recompile Python for the X86 64 bit architecture. When doing this, it is preferable, and may actually be necessary, to ensure that the '--enable-shared' option is provided to the 'configure' script for Python when it is being compiled and installed.

If rebuilding Python to generate a shared library, do make sure that the Python shared library, or a symlink to it appears in the Python 'config' directory of your Python installation. If the shared library doesn't appear here next to the static version of the library, 'libtool' will not be able to find it and will still use the static version of the library. It is understood that the Python build process may not actually do this, so you may have to do it by hand.

If the version of Python being used was compiled for X86 64 bit architecture and a shared library does exist, but not in the 'config' directory, then adding the missing symlink may be all that is required. [/quote]

--Gilbert