[Distutils] Building extension on FreeBSD with Py_ENABLE_SHARED

Nicholas Bastin nick.bastin at gmail.com
Fri Jan 8 04:19:12 CET 2010

(This comes from trying to build python with --enable-shared, but I
think the problem is not in the Python build process, but rather in
distutils itself)

When building python standard extensions as part of the build process
from ./configure --enable-shared in 2.7 trunk on freebsd5, all the
modules fail because they can't find libpython2.7.so:

building '_json' extension
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I./Include -I/usr/local/include -IInclude
-I/u1/Python/Python-2.7a1 -c /u1/Python/Python-2.7a1/Modules/_json.c
-o build/temp.freebsd-5.3-RELEASE-i386-2.7/u1/Python/Python-2.7a1/Modules/_json.o
gcc -shared build/temp.freebsd-5.3-RELEASE-i386-2.7/u1/Python/Python-2.7a1/Modules/_json.o
-L/usr/local/lib -lpython2.7 -o
/usr/bin/ld: cannot find -lpython2.7

This is because libpython2.7.so is in '.' (pre-install), and -L. isn't
on the compile command.  This problem doesn't happen on linux or
solaris, but it turns out that's because it's special-cased in

        # for extensions under Linux or Solaris with a shared Python library,
        # Python's library directory must be appended to library_dirs
        if ((sys.platform.startswith('linux') or sys.platform.startswith('gnu')
             or sys.platform.startswith('sunos'))
            and sysconfig.get_config_var('Py_ENABLE_SHARED')):
            if sys.executable.startswith(os.path.join(sys.exec_prefix, "bin")):
                # building third party extensions
                # building python standard extensions

Adding freebsd to the list of platforms in question solves my
particular problem, although I don't know enough about distutils to
know if this would cause some other problem.  Is there any particular
reason we should not add '.' to the list of library_dirs on freebsd?


More information about the Distutils-SIG mailing list