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

Thanks for the detailed reply.  I really dont want to have to compile 
anything if I can help it and I would rather use the binary. Trouble is 
I want to use fts3 - that is why I am trying apsw rather than sqlite3.

Traceback (most recent call last):
  File "C:\Users\sg\Desktop\Dass\hashpid.py", line 27, in <module>
    for a in cursor.execute ("select labno from ft limit 10"):
  File "src/cursor.c", line 986, in APSWCursor_execute.sqlite3_prepare_v2
SQLError: SQLError: no such module: fts3

ft is a virtual fts3 table prepared with the DOS sqlite program.  It 
works under this program.

I have tried dowloading the latest DLL from www.sqlite.com. They dont 
explicitly say with this has fts3 build in or not so I have tried 
compiling form the amalgamation,  which should included fts3 by default 
in the dll version. I overwrote the python dll but this doesn't work either.


Roger Binns wrote:
> -----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-----
> _______________________________________________
> list-pysqlite mailing list
> list-pysqlite-FR6EJeJVuqdwc357pe9rcyQmJico6nz3epZhswDD4dQ@public.gmane.org
> http://itsystementwicklung.de/cgi-bin/mailman/listinfo/list-pysqlite
>