Re: [pysqlite] Compiled apsw on windows with no errors but it doesnt work

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stuart wrote:
> I downloaded the latest version of apsw for python.  I used setup.py 
> install (I had previously done a --fetch.sqlite to get the latest 
> version of sqlite.)  

The latest APSW on the website includes the latest SQLite release.  FTS3
and Rtree are enabled in the Windows binary distribution by default so
you haven't really achieved anything :-)

> I have no idea where to look for a fix.  Any ideas would be gratefully 
> accepted.

It is actually a bug in MinGW that you hit. If you want to just get up
and running then I'd recommend using the binary distribution.  Long
information follows:

> ImportError: DLL load failed: The specified procedure could not be found.

This is where the symptoms show themselves.  When Windows loaded the
apsw DLL, it referenced a symbol in another DLL that doesn't exist.
Windows helpfully omits to mention what the DLLs or symbols involved are.

This may seem rather user hostile but it actually a situation that
shouldn't happen.  When the developer does the link stage after
compilation all the various symbols should be resolved and errors
generated for missing ones.  How does the compilation system know which
symbols are in which DLLs?  This is usually done by having .lib files
corresponding to each DLL with the .lib files listing the symbols.  Some
modern compilation systems can look directly in the DLL for symbols
although that is not happening with the MinGW version you are using.

Separately Microsoft also decided to keep releasing new versions of
their C library, usually with a release corresponding to each release of
Visual Studio.  They also have a weaker versioning scheme than used on
other systems such as Unix.  And then they decided to mess with things
like where some symbols are implemented.  The Python dev team also
decided to use different MSVC versions for almost every Python release
(generally whatever was modern/stable at the time).  The huge resulting
mess is C library versions all over the place, symbols all over the
place and Python usage of MSVC all over the place.

The MinGW developers also maintain their list of what symbols are in
what Microsoft DLLs by hand since automatically generating would be
considered a derived work and presumably violate licensing.  They
shipped MinGW saying that MSVC version 9 shared library had localtime()
when it didn't.  They also claim to not support anything except the
plain (unnumbered) MSVC C library and so technically do not support
Python with MSVC.

The quick solution is to regenerate the MinGW .lib that corresponds to
MSVC 9 C library.  You need to use pexports and dlltool to do so.  MinGW
was updated a year ago but who knows when that actually get released.

MinGW postings about this issue (scroll past the big calendar):

  http://preview.tinyurl.com/lzmqqg

Roger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkpVNGIACgkQmOOfHg372QTHTACdHZN5ZfUF9fo9LAcLrWmIxjYv
AkQAn3L+/VgagcLpQGJFyy6cHPQCAfOS
=d1uv
-----END PGP SIGNATURE-----