access to C struct to support statically linking spatialite

Background

Spatialite can be initialized in two ways. Most commonly mod_spatialite is loaded via sqlite APIs, which eventually use dlopen to dynamically load the shared library. This doesn't allow for statically linking spatialite. Additionally if sqlite is statically linked it can't load extensions because dlopen doesn't work.

The other option is to link libspatialite into the binary and initialize spatialite on the sqlite3 handle via spatialite's C API.

Roughly:

var db *C.sqlite3
C.sqlite3_open_v2(..., &db, ...)

cache := C.spatialite_alloc_connection()
C.spatialite_init_ex(db, cache, 0)

This method does allow for static linking.

Request

I have a need to build fully static binaries including sqlite/spatialite. I don't think it would be reasonable to ask that this be directly supported in this library since spatialite isn't designed to be self contained and easy to compile like the sqlite amalgamation. It would be helpful to be able to access the *C.sqlite3 struct without forking the library though.

Would you consider providing a way to access *C.sqlite3 from the connection? Even if it's a method like UnsafeDontAskForSupport() *C.sqlite3 😀.

Thanks for the library and considering this request!

Aside: If you're wondering about the potential leak of the allocation by C.spatialite_alloc_connection(), my solution is to wrap the go-sqlite3 driver.Driver and driver.Conn so that it can be freed when the connection is closed.

No file or test path is named. Start by locating the connection implementation and how its underlying C.sqlite3 handle is opened and stored, then trace the driver and connection lifecycle. Done means a supported way to obtain that handle for the spatialite C API, with a focused test or documented verification of the access path; the long-unanswered API request needs maintainer guidance.