Issue 5674: distutils fails to find Linux libs (lib.....so.n) (original) (raw)

Issue5674

Created on 2009-04-02 21:22 by jgarrison, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (3)
msg85268 - (view)	Author: Jim Garrison (jgarrison)	Date: 2009-04-02 21:22
Trying to build 3.1a1 on Fedora 9, the following extensions get skipped even though the requisite packages are installed _dbm _gdbm _hashlib _sqlite3 _ssl bz2 readline zlib After looking at the code in distutils I *think* the problem is because setup.py isn't coping with library filenames such as "libreadline.so.5" and "libgdm.so.2" (with the .n) second extension. It looks like ccompiler.py#library_filename() just appends the extension, which is .so for unix, and then unixccompiler.py#find_library_file() does a simple os.path.exists() on the name, not allowing for the additional numeric extension. Note that some library filenames in Linux have two or even three such extensions, as in libreadline.so.5.2, and some extensions are not all-numeric, as in libssl.so.0.9.8g.
msg85378 - (view)	Author: R. David Murray (r.david.murray) *	Date: 2009-04-04 07:24
Are you sure it isn't your Fedora installation that has the problem? My understanding is that the linker name (the libxxx.so name) should exist and be a symbolic link to the most recent soname (libxxx.N). So I think distutils is doing the right thing. See for example http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html, the first section of which (I didn't read the whole thing) matches my understanding of how this works. Do you have any doc pointers that says Fedora doesn't work this way? (Note that the libxxx.so linker name may not be in the same directory as the sonames or the actual library files.)
msg85421 - (view)	Author: Martin v. Löwis (loewis) *	Date: 2009-04-04 18:10
I agree with David. The .so name must exist; if it doesn't, your installation does indeed lack the necessary prerequisite. Closing as invalid.