Using apsw with pysqlite2 through static bundling of libsqlite3.a?

[Sriram Karra]

Roger - with your help I have managed to compile apsw and pysqlite2 with the same shared libsqlite3.dylib shared library. This is fine, except that it presents problems with distribution as it presupposes availability of the shared library at a fixed location.

The constraints of my application are:

a) Developed on Mac but expected to run on Mac and Windows

b) Self-contained with all required non-standard libraries and modules

c) Should not require any installation or super user privilges

How can I bundle up pysqlite2 and apsw such that the all of the above could be achieved? I was trying to explore if we can statically link all of them into a single module. Can you give some pointers on whether that is possible, and if yes how?

-Karra

[Roger Binns]

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

On 07/03/13 05:06, Sriram Karra wrote:
> This is fine, except that it presents problems with distribution as it
> presupposes availability of the shared library at a fixed location.

Where do you get "fixed location" from? Windows automatically prepends
the app directory to the shared library path, and Mac should have some
sort of equivalent of $LD_LIBRARY_PATH and possibly rpath.

> How can I bundle up pysqlite2 and apsw such that the all of the above
> could be achieved? I was trying to explore if we can statically link
> all of them into a single module. Can you give some pointers on whether
> that is possible, and if yes how?

No idea about pysqlite - you'll need to look into that - but last I looked
it consisted of several C and Python files. APSW produces a single object
file so that can be statically linked into whatever you need. The only
public symbol from the APSW object file is initapsw which is the entry
point for loadable Python extensions. I suspect Python won't like loading
the same file twice as differently named extensions.

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

iEYEARECAAYFAlE4kqoACgkQmOOfHg372QSjKQCdH4cVYENmVm1LE4uHdttDOjjS
OtwAn0djiwmfYfFrJZPNFCMf0tmi+psX
=n3SV
-----END PGP SIGNATURE-----

[Sriram Karra]

On Thursday, 7 March 2013 18:44:24 UTC+5:30, Roger Binns wrote:

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

On 07/03/13 05:06, Sriram Karra wrote:
> This is fine, except that it presents problems with distribution as it
> presupposes availability of the shared library at a fixed location.

Where do you get "fixed location" from?  Windows automatically prepends
the app directory to the shared library path, and Mac should have some
sort of equivalent of $LD_LIBRARY_PATH and possibly rpath.

otool -L apsw.so shows a dependency on libsqlite3.dylib with a hard code path, and that's what get loaded. 

[Roger Binns]

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

On 07/03/13 06:19, Sriram Karra wrote:
> otool -L apsw.so shows a dependency on libsqlite3.dylib with a hard
> code path, and that's what get loaded.

That is traditionally called rpath as I mentioned. Doing a Google search
should show some way of removing/altering it.

Roger

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

iEYEARECAAYFAlE4/jQACgkQmOOfHg372QShEgCg3TfPF/7A7DvMm0yy9zUWIA2F
NQMAn2JXssHu/KssZHOFrh/12yZIWXKW
=1ijM
-----END PGP SIGNATURE-----