Building extension on FreeBSD with Py_ENABLE_SHARED
(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
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
On Sat, Jan 9, 2010 at 05:04, Floris Bruynooghe
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.
I'll put a patch on that issue today. I've tested on freebsd5 and it works - I'd like to at least test on freebsd6, and if someone else has access to more modern versions, that would be good to test as well. -- Nick
On Sat, Jan 9, 2010 at 05:04, Floris Bruynooghe
Searching throug the tracker I found this: http://bugs.python.org/issue4366, which looks the same issue.
I've added a patch from 2.7 and comment to this issue (apologies for failing to find it on my first seach). I'm grabbing a checkout of 3.2 trunk now so I can make a patch there as well. Which leaves only a few questions: * Does anyone think this isn't the proper fix? * Should it be patched in 26-maint and 31-maint as well? -- Nick
participants (3)
-
"Martin v. Löwis" -
Floris Bruynooghe -
Nicholas Bastin