[Python-Dev] --enabled-shared broken on freebsd5?
nick.bastin at gmail.com
Wed Jan 6 22:14:54 CET 2010
(This may occur on more platforms - I can test on more unix platforms
if the consensus is this is an actual problem and I'm not just a nut)
On freebsd5, if you do a simple ./configure --enable-shared in current
(2.7) trunk, your python shared library will build properly, but all
modules will fail to find the shared library and thus fail to build:
gcc -shared build/temp.freebsd-5.3-RELEASE-i386-2.7/u1/Python/Python-2.7a1/Modules/_struct.o
-L/u1/tmp/python2.7a1/lib -L/usr/local/lib -lpython2.7 -o
/usr/bin/ld: cannot find -lpython2.7
building '_ctypes_test' extension
This of course is because libpython2.7.so is in the current directory
and not (yet) installed in /usr/local/lib. I've made a very simple
fix for this problem that works, but at least to me smells a bit
funny, which is to modify setup.py to add the following to
# If we did --enable-shared, we need to be able to find the library
# we just built in order to build the modules.
if platform == 'freebsd5':
Which brings me to a few questions:
a) Does this seem like a real problem, or am I missing something obvious?
b) Does this fix seem like the sensible thing to do? (it seems at
least that we ought to check that the user configured --enable-shared
and only set -L. in that case, if that's possible)
Setting --enable-shared when you actually have a libpython2.7.so in
/usr/local/lib (or whatever --prefix you've selected) is possibly even
more dangerous, because it may succeed in linking against a
differently-built library than what you intended.
More information about the Python-Dev