[issue5674] distutils fails to find Linux libs (lib.....so.n)
R. David Murray rdmur...@bitdance.com added the comment: 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.) -- nosy: +r.david.murray priority: - normal ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5674 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5674] distutils fails to find Linux libs (lib.....so.n)
Martin v. Löwis mar...@v.loewis.de added the comment: I agree with David. The .so name must exist; if it doesn't, your installation does indeed lack the necessary prerequisite. Closing as invalid. -- nosy: +loewis resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5674 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5674] distutils fails to find Linux libs (lib.....so.n)
New submission from Jim Garrison jgarri...@troux.com: 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. -- assignee: tarek components: Distutils messages: 85268 nosy: jgarrison, tarek severity: normal status: open title: distutils fails to find Linux libs (lib.so.n) type: compile error versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5674 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
