| msg31882 - (view) |
Author: Vitaliy Yermolenko (vitalyy2000) |
Date: 2007-04-24 19:18 |
| Failed to build new Python 2.5.1 with default config options, except --prefix, from Python-2.5.1.tar.bz2 on x86_64 (GNU/Linux 2.6.18-1.2798.fc6) with preliminary installed sqlite 3.3.6 - see below: -- BEGIN -- [skipped] running build running build_ext db.h: found (4, 3) in /usr/include db lib: using (4, 3) db-4.3 sqlite: found /usr/include/sqlite3.h /usr/include/sqlite3.h: version 3.3.6 Traceback (most recent call last): File "./setup.py", line 1525, in main() File "./setup.py", line 1520, in main 'Lib/smtpd.py'] File "/tmp/070421/Python-2.5.1/Lib/distutils/core.py", line 151, in setup dist.run_commands() File "/tmp/070421/Python-2.5.1/Lib/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/tmp/070421/Python-2.5.1/Lib/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/tmp/070421/Python-2.5.1/Lib/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/tmp/070421/Python-2.5.1/Lib/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/tmp/070421/Python-2.5.1/Lib/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/tmp/070421/Python-2.5.1/Lib/distutils/command/build_ext.py", line 290, in run self.build_extensions() File "./setup.py", line 97, in build_extensions self.detect_modules() File "./setup.py", line 795, in detect_modules sqlite_libdir = [os.path.abspath(os.path.dirname(sqlite_libfile))] File "/tmp/070421/Python-2.5.1/Lib/posixpath.py", line 119, in dirname return split(p)[0] File "/tmp/070421/Python-2.5.1/Lib/posixpath.py", line 77, in split i = p.rfind('/') + 1 AttributeError: 'NoneType' object has no attribute 'rfind' make: *** [sharedmods] Error 1 --- END --- Workaround: once /usr/include/sqlite3.h was "avoided" (actually just temporarily renamed), the installation was completed successfully. -+--> WBR, Vitaliy Yermolenko. |
|
|
| msg57751 - (view) |
Author: Gerhard Häring (ghaering) *  |
Date: 2007-11-22 10:16 |
| This is apparently a problem in setup.py. There seems to be a code path where an object should be a string, but is None instead. I'll have to review the relevant parts of setup.py. |
|
|
| msg62888 - (view) |
Author: Eh Tan (tan2) |
Date: 2008-02-24 09:13 |
| The problem is at line 890, setup.py, r60970. sqlite_libfile = self.compiler.find_library_file( sqlite_dirs_to_check + lib_dirs, 'sqlite3') sqlite_libdir = [os.path.abspath(os.path.dirname(sqlite_libfile))] self.compiler.find_library_file() will return None if the library is not found. The code passes None to os.path.dirname and cause the error. |
|
|
| msg72863 - (view) |
Author: Jason Tishler (jlt63) *  |
Date: 2008-09-09 14:10 |
| The Cygwin build is having the same problem: http://cygwin.com/ml/cygwin/2008-09/msg00145.html In this case, the sqlite3 libraries are installed (in /usr/lib), but their suffixes do not match the expected values. Does anyone know the best way to make setup.py and/or distutils search for .dll.a instead of .dll? |
|
|
| msg73511 - (view) |
Author: Hirokazu Yamamoto (ocean-city) * |
Date: 2008-09-21 12:24 |
| >AttributeError: 'NoneType' object has no attribute 'rfind' Fixing this error is not difficult. I think attached patch is enough. But still cygwin user who wants to use sqlite3 module won't be happy. find_library() supports static lib, shared lib, and dylib but ".dll.a" seems to be windows specific import library. Probably disutils itself need to be modified. (And probably it's too late for RC phase :-() |
|
|
| msg73654 - (view) |
Author: Roumen Petrov (rpetrov) * |
Date: 2008-09-23 19:13 |
| The search for *dll.a is described in paragraph "direct linking to a dll" here: http://sourceware.org/binutils/docs/ld/WIN32.html |
|
|
| msg73661 - (view) |
Author: Jason Tishler (jlt63) * |
Date: 2008-09-23 19:56 |
| The Cygwin build issue was worked around by releasing a sqlite3 package that contains a static library too. However, this causes the Python _sqlite module to be statically linked against sqlite3 even though a shared library version is available. The following patch enables Cygwin to leverage off on the ".dylib" functionality added (AFAICT) for Mac OS X. After the patch is applied, the _sqlite module is linked against the shared sqlite3 library instead of the static one. Is the patch acceptable? Or, can someone think of a better approach? |
|
|
| msg73664 - (view) |
Author: Roumen Petrov (rpetrov) * |
Date: 2008-09-23 20:26 |
| I think that modification has to be in cygwinccompiler. It is specific for win32 binutils and impact both - cygwin and mingw. |
|
|
| msg73665 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2008-09-23 20:34 |
| +1 for adding dylib_lib_extension = ".dll.a" to the CygwinCCompiler class. |
|
|
| msg73675 - (view) |
Author: Hirokazu Yamamoto (ocean-city) * |
Date: 2008-09-23 22:39 |
| Python is not using CCygwinCCompiler to build itself on cygwin. See . |
|
|
| msg73695 - (view) |
Author: Roumen Petrov (rpetrov) * |
Date: 2008-09-24 09:28 |
| If Jason patch resolve issue may I ask cygwincompiler.py to be modified too just in case if as result of is decided to switch back ? |
|
|
| msg73705 - (view) |
Author: Jason Tishler (jlt63) * |
Date: 2008-09-24 11:33 |
| Hirokazu Yamamoto wrote: > Python is not using CCygwinCCompiler to build itself on cygwin. Which I why my patch modifies UnixCCompiler instead of CCygwinCCompiler. FWIW, my patch leverages the already existing Cygwin specific code in UnixCCompiler. So, is my patch acceptable? |
|
|
| msg73747 - (view) |
Author: Hirokazu Yamamoto (ocean-city) * |
Date: 2008-09-24 18:41 |
| >So, is my patch acceptable? Umm, it works, but I'm not sure we can call import library as dylib... If it's not problem, I think your patch is fine. # I had considered attached patch "experimental_distutils.patch". It's little adhoky, I'm not sure this patch is acceptable. |
|
|
| msg73754 - (view) |
Author: Roumen Petrov (rpetrov) * |
Date: 2008-09-24 20:57 |
| About experimental_distutils.patch - extra changes that has to go in a specific compiler class. As example platform can be any but compiler gcc(mingw) that produce executables for windows host platform. In this case search has to include suffix .dll.a. |
|
|
| msg73787 - (view) |
Author: Jason Tishler (jlt63) * |
Date: 2008-09-25 13:04 |
| Hirokazu Yamamoto wrote: > Umm, it works, but I'm not sure we can call import library as > dylib... Agreed. > I had considered attached patch "experimental_distutils.patch". > It's little adhoky, I'm not sure this patch is acceptable. The new functionality is very similar to what I suggested in . Although it would be better to put Cygwin specific behavior in CygwinCCompiler, I think the changes would have be more invasive if you did. I prefer your approach to mine. Can we get consensus and move forward? |
|
|
| msg73885 - (view) |
Author: Hirokazu Yamamoto (ocean-city) * |
Date: 2008-09-26 20:32 |
| >extra changes that has to go in a >specific compiler class. As example platform can be any but compiler >gcc(mingw) that produce executables for windows host platform. You are right. It should be. My patch is just one choice when switching back to CygwinCCompiler is difficult. (Anyway I don't understand well why CygwinCCompiler was abandoned) >it would be better to put Cygwin specific behavior >in CygwinCCompiler, I think the changes would have be more invasive if >you did. Agreed. |
|
|
| msg73893 - (view) |
Author: Roumen Petrov (rpetrov) * |
Date: 2008-09-26 21:43 |
| no objections |
|
|
| msg74264 - (view) |
Author: Hirokazu Yamamoto (ocean-city) * |
Date: 2008-10-03 17:38 |
| I've committed "fix_sqlite3_setup_error.patch" in r66766. I think the problem disutils cannot recognize .dll.a as library on cygwin is another issue, so I'll open new tracker item. |
|
|