3.6.18 doesn't build against vendor built sqlite

[rogerbinns]

From bchesneau on September 13, 2009 04:45:10

Just launched tests and got :

enlil-2:apsw benoitc$ sudo python setup.py install
SQLite: Using system sqlite include/libraries
running install
running build
running build_ext
building 'apsw' extension
creating build
creating build/temp.macosx-10.6-universal-2.6
creating build/temp.macosx-10.6-universal-2.6/src
gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -Os
-Wall -Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch ppc -arch x86_64
-pipe -DEXPERIMENTAL=1 -DNDEBUG=1 -Isrc
-I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c
src/apsw.c -o build/temp.macosx-10.6-universal-2.6/src/apsw.o
creating build/lib.macosx-10.6-universal-2.6
gcc-4.2 -Wl,-F. -bundle -undefined dynamic_lookup -arch i386 -arch ppc
-arch x86_64 build/temp.macosx-10.6-universal-2.6/src/apsw.o -lsqlite3 -o
build/lib.macosx-10.6-universal-2.6/apsw.so
running install_lib
copying build/lib.macosx-10.6-universal-2.6/apsw.so ->
/Library/Python/2.6/site-packages
running install_egg_info
enlil-2:apsw benoitc$ python tests.py
Traceback (most recent call last):
File "tests.py", line 9, in
import apsw
ImportError: dlopen(/Library/Python/2.6/site-packages/apsw.so, 2): Symbol
not found: _sqlite3_enable_load_extension
Referenced from: /Library/Python/2.6/site-packages/apsw.so
Expected in: flat namespace
in /Library/Python/2.6/site-packages/apsw.so

Original issue: http://code.google.com/p/apsw/issues/detail?id=67

[rogerbinns]

From rogerbinns on September 13, 2009 05:17:07

Your SQLite is built with -DSQLITE_OMIT_LOAD_EXTENSION so you need to build APSW with
the same flags (it has no way of guessing). See the last bit of http://apsw.googlecode.com/svn/publish/build.html#finding-sqlite-3

Status: Invalid
Labels: -Type-Defect Type-Other

[rogerbinns]

From bchesneau on September 13, 2009 05:54:21

well issue is valid.... This is to the packager to make sure that its stuff works on
most platform. Anyway, here is a patch that allow build to work on snow leopard with
default sqlite.

Attachment: apsw_setup.py.patch

[rogerbinns]

From rogerbinns on September 13, 2009 06:00:41

That patch is bogus because it unilaterally disables loadable extensions on all Macs!
It does not take into account if the recommended APSW build instructions have been
followed (in which case a private SQLite is used) or if a self installed SQLite is
being used.

It only works for the case of the Apple supplied SQLite where they have disabled
extension loading (SQLite default is extension loading code is present - it still has
to be enabled via C calls before use).

Additionally the next APSW release will require SQLite 3.6.18 at a minimum and
possibly 3.7.0, neither of which Apple will be supplying for a long time.

[rogerbinns]

From bchesneau on September 13, 2009 06:10:50

there are many other way to detect sqlite like using a little c code to do it like
autotools would do. pysqlite seem to do it. Purpose of this patch is to show that's
it's possible to detect/or set default in setup.py.

Which is the main objectiv of packaging ie provide the default. Rather than closing
the bug I would suggest to let it open and finding a way to properly handle a default
setup.

[rogerbinns]

From rogerbinns on September 13, 2009 06:33:10

I understand your frustration, but lets be clear that it is Apple who changed the
default, and within a month (the next SQLite and APSW releases) you won't even be
able to use the Apple supplied SQLite anyway as it is too old. I also clearly
document a recommended way of doing all this which results in things just working.
(There is a world of hurt in earlier MacOS versions if you do not use the
amalgamation as MacOS will go out of its way to use a different version of the
library than you linked against and keep telling it to use.)

pysqlite does not do any detection - it ships source with extension loading omitted
by default. When it downloads the amalgamation it doesn't even bother to get the
right defines - something APSW does do.

The environment of code running within setup.py is particularly horrible hence the
plethora of additions and alternatives like setuptools and pip. You are welcome to
provide a patch that correctly detects at build time whether extension loading should
be enabled or disabled "using a little c code". (It should detect the correct
setting, not just unilaterally set/unset it based on hard coded platform information.)

Some example fun reading: http://cournape.wordpress.com/2009/04/01/python-packaging-a-few-observations-cabal-for-a-solution/

[rogerbinns]

From rogerbinns on September 17, 2009 17:47:52

After playing around a bit more I've thought of an alternate approach.

When using the amalgamation then default to load extension being enabled otherwise
default to it being disabled. This should catch almost all cases and for the
remainder the apsw builder will have to specify the --omit/--enable as appropriate.

Summary: 3.6.18 doesn't build against vendor built sqlite
Status: Accepted

[rogerbinns]

From rogerbinns on September 25, 2009 19:50:56

Revision be112563b8 changes the defaults so extension loading is on when using the
amalgamation and off when using external libraries. You can still explicitly pick
the setting with --enable/--omit=load_extension

Status: Verified