[Python-Dev] --enabled-shared broken on freebsd5?

[Nicholas Bastin]

(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
build/lib.freebsd-5.3-RELEASE-i386-2.7/_struct.so
/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
detect_modules():

        # 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':
            add_dir_to_list(self.compiler_obj.library_dirs, '.')


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.

--
Nick