(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 build/lib.freebsd-5.3-RELEASE-i386-2.7/_json.so /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 distutils.command.build_ext.finalize_options:278: # for extensions under Linux or Solaris with a shared Python library, # Python's library directory must be appended to library_dirs sysconfig.get_config_var('Py_ENABLE_SHARED') 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 self.library_dirs.append(sysconfig.get_config_var('LIBDIR')) else: # building python standard extensions self.library_dirs.append('.') 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? -- Nick