[Bro-Dev] Linking problem on Linux
gc355804 at ohio.edu
Thu Oct 6 09:01:51 PDT 2011
Oh, actually, this may be relevant as well...
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.
On 10/6/2011 11:55 AM, Gilbert Clark wrote:
> +1 this.
> On 10/6/2011 11:45 AM, Jonathan Siwek wrote:
>>> 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
>> bro-dev mailing list
>> bro-dev at bro-ids.org
> bro-dev mailing list
> bro-dev at bro-ids.org
More information about the bro-dev