Hi Nicholas On Thu, Jan 07, 2010 at 10:19:12PM -0500, Nicholas Bastin wrote:
(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:
Searching throug the tracker I found this: http://bugs.python.org/issue4366, which looks the same issue.
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?
Your solution is better tough, If you don't I'll try to create and test a patch for it by the end of the weekend. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org