[Distutils, Python3] Incorrect shared library extension on linux

Hello, First: I'm using Python3 as available in Fedora rawhide (python3-3.3.0-2.fc19.x86_64). Attempting to build a project using python3/distutils, I noticed that find_library_file would not find any library at all. Some investigation showed that this was due to the fact that libraries were searched with the ".cpython-33m.so" extension. Even more investigation showed that the library extension was read being overridden by the one defined in the /usr/lib64/python3.3/config-3.3m/Makefile shipped by python3-libs. See below for the detailed analysis. The python-versioned extension obviously makes no sense for regular shared objects which are not python binary modules, so this is clearly wrong. As a workaround I commented sysconfig.py@customize_compiler::235 (compiler.shared_lib_extension = so_ext, see below), and things seem to work. Is this a distribution bug or an upstream bug? Thanks, Sandro Detailed analysis: setup.py: def _find_library_file(self, library): return self.compiler.find_library_file(self.compiler.library_dirs, library) --- In function /usr/lib64/python3.3/distutils/unixcompiler.py@find_library_file::266: shared_f = self.library_filename(lib, lib_type='shared') In function /usr/lib64/python3.3/distutils/ccompiler.py@library_filename::882: ext = getattr(self, lib_type + "_lib_extension") -> Where does shared_lib_extension get defined? * At /usr/lib64/python3.3/distutils/ccompiler.py::66 shared_lib_extension = None -> default for abstract class * At /usr/lib64/python3.3/distutils/unixcompiler.py::77 shared_lib_extension = ".so" -> this is the correct value * In function /usr/lib64/python3.3/distutils/sysconfig.py@customize_compiler::235 by /usr/lib64/python3.3/distutils/sysconfig.py@customize_compiler::235 compiler.shared_lib_extension = so_ext by /usr/lib64/python3.3/distutils/sysconfig.py@customize_compiler::194 (cc, cxx, opt, cflags, ccshared, ldshared, so_ext, ar, ar_flags) = \ get_config_vars('CC', 'CXX', 'OPT', 'CFLAGS', 'CCSHARED', 'LDSHARED', 'SO', 'AR', 'ARFLAGS')) by /usr/lib64/python3.3/distutils/sysconfig.py@get_config_vars::530 526 global _config_vars 527 if _config_vars is None: 528 func = globals().get("_init_" + os.name) # -> os.name = posix 529 if func: 530 func() # -> _init_posix, populates _config_vars by /usr/lib64/python3.3/distutils/sysconfig.py@_init_posix::439 435 g = {} 436 # load the installed Makefile: 437 try: 438 filename = get_makefile_filename() # /usr/lib64/python3.3/config-3.3m/Makefile 439 parse_makefile(filename, g) ... 476 global _config_vars 477 _config_vars = g # -> _config_vars["SO"] = ".cpython-33m.so" by /usr/lib64/python3.3/config-3.3m/Makefile::122 SO= .cpython-33m.so

Hello, On Sat, 22 Dec 2012 20:36:04 +0100 Sandro Mani <manisandro@gmail.com> wrote:
Hello,
First: I'm using Python3 as available in Fedora rawhide (python3-3.3.0-2.fc19.x86_64).
Attempting to build a project using python3/distutils, I noticed that find_library_file would not find any library at all. Some investigation showed that this was due to the fact that libraries were searched with the ".cpython-33m.so" extension. Even more investigation showed that the library extension was read being overridden by the one defined in the /usr/lib64/python3.3/config-3.3m/Makefile shipped by python3-libs. See below for the detailed analysis. The python-versioned extension obviously makes no sense for regular shared objects which are not python binary modules, so this is clearly wrong. As a workaround I commented sysconfig.py@customize_compiler::235 (compiler.shared_lib_extension = so_ext, see below), and things seem to work.
Is this a distribution bug or an upstream bug?
Probably an upstream bug, I suggest you file it at http://bugs.python.org. Regards Antoine.
participants (2)
-
Antoine Pitrou
-
Sandro Mani