classification
Title: Failed to build Python 2.5.1 with sqlite3
Type: compile error Stage:
Components: Build, Distutils Versions: Python 2.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: amaury.forgeotdarc, ghaering, jlt63, ocean-city, rpetrov, tan2, vitalyy2000
Priority: normal Keywords: patch

Created on 2007-04-24 19:18 by vitalyy2000, last changed 2008-10-03 17:38 by ocean-city. This issue is now closed.

Files
File name Uploaded Description Edit
fix_sqlite3_setup_error.patch ocean-city, 2008-09-21 12:24
unixccompiler.py.diff jlt63, 2008-09-23 19:56
experimental_distutils.patch ocean-city, 2008-09-24 18:41
Messages (18)
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 <module>
    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) * (Python committer) 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) * (Python triager) 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) * (Python committer) 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) * (Python triager) 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) * (Python committer) 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) * (Python committer) Date: 2008-09-23 22:39
Python is not using CCygwinCCompiler to build itself on cygwin. See
issue2445.
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 issue2445 is decided to switch back ?
msg73705 - (view) Author: Jason Tishler (jlt63) * (Python triager) 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) * (Python committer) 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) * (Python triager) 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 
issue2445. 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) * (Python committer) 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) * (Python committer) 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.
History
Date User Action Args
2008-10-03 17:38:36ocean-citysetstatus: open -> closed
resolution: fixed
messages: + msg74264
2008-09-27 23:16:13ocean-citysetkeywords: - needs review
2008-09-26 21:43:34rpetrovsetmessages: + msg73893
2008-09-26 20:32:41ocean-citysetmessages: + msg73885
2008-09-25 13:04:10jlt63setmessages: + msg73787
2008-09-24 20:57:59rpetrovsetmessages: + msg73754
2008-09-24 18:41:15ocean-citysetfiles: + experimental_distutils.patch
messages: + msg73747
components: + Distutils
2008-09-24 11:33:00jlt63setmessages: + msg73705
2008-09-24 09:28:31rpetrovsetmessages: + msg73695
2008-09-23 22:39:57ocean-citysetmessages: + msg73675
2008-09-23 20:34:38amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg73665
2008-09-23 20:26:18rpetrovsetmessages: + msg73664
2008-09-23 19:56:01jlt63setfiles: + unixccompiler.py.diff
messages: + msg73661
2008-09-23 19:13:19rpetrovsetnosy: + rpetrov
messages: + msg73654
2008-09-23 17:16:54ocean-citysetkeywords: + needs review
2008-09-21 12:24:54ocean-citysetfiles: + fix_sqlite3_setup_error.patch
nosy: + ocean-city
messages: + msg73511
keywords: + patch
2008-09-09 14:10:29jlt63setnosy: + jlt63
messages: + msg72863
2008-02-24 09:13:32tan2setnosy: + tan2
messages: + msg62888
2007-11-22 10:16:54ghaeringsettype: compile error
messages: + msg57751
nosy: + ghaering
2007-04-24 19:18:41vitalyy2000create