Bug report #4030
1.7.0 Build failure with internal spatialite on OpenBSD
Status: | Closed | ||
---|---|---|---|
Priority: | Normal | ||
Assignee: | - | ||
Category: | Build/Install | ||
Affected QGIS version: | master | Regression?: | No |
Operating System: | OpenBSD | Easy fix?: | No |
Pull Request or Patch supplied: | No | Resolution: | fixed |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 14016 |
Description
In 1.7.0, the build fails on OpenBSD (gcc 4.2.1) during the linking of qgis binary with undefined references to the sqlite* symbols, which are typedefined 4 times to SPLite* syms in src/core/spatialite/*.
CMakeFiles/qgis.dir/qgisapp.cpp.o(.text+0x49e5): In function `QgisApp::createDB()':
: undefined reference to `sqlite3_open'
CMakeFiles/qgis.dir/qgisapp.cpp.o(.text+0x4abe): In function `QgisApp::createDB()':
: undefined reference to `sqlite3_exec'
....
CMakeFiles/qgis.dir/spatialite/qgsspatialitesridsdialog.cpp.o(.text+0x1282): In function `QgsSpatialiteSridsDialog::on_pbnFilter_clicked()':
: undefined reference to `sqlite3_finalize'
CMakeFiles/qgis.dir/spatialite/qgsspatialitesridsdialog.cpp.o(.text+0x12e6): In function `QgsSpatialiteSridsDialog::on_pbnFilter_clicked()':
: undefined reference to `sqlite3_errmsg'
../core/libqgis_core.so.5.0: undefined reference to `sqlite3_column_count'
../gui/libqgis_gui.so.4.0: undefined reference to `sqlite3_column_int'
../core/libqgis_core.so.5.0: undefined reference to `sqlite3_column_name'
../core/libqgis_core.so.5.0: undefined reference to `sqlite3_bind_text'
Putting the #define list within #ifndef OpenBSD (see attached patches) fixes the build for me, but i'm puzzled. I understand why the #defines are here to avoid symbol conflicts, but i don't understand why it fails to build.
History
#1 Updated by Sandro Furieri over 13 years ago
Hi Landry,
just a basic explanation; libspatialite comes in two
different flavors:
1) standard "libspatialite" depends on external libsqlite3
2) on the other side "libspatialite-amalgamation" includes
an internal private copy of libsqlite3: so no further
dependencies are required, and in this case libspatialite
alone can be used a full replacement for libsqlite3
Please Note: the QGIS "internal spatialite" actually is
the same of "libspatialite-amalgamation".
Anyway, a subtle distinction exists between them: in order
to avoid any obnoxious side effect when libspatialite-amalgamation
and libsqlite3 are (wrongly) linked at the same time, any
export/link symbol referencing some sqlite's own API will be
silently renamed in the "amalgamated" library.
i.e. "sqlite3_bind_text" becomes "SPLite3_bind_text" and so on.
All the magic about such symbol renaming simply is defined
in the sqlite3.h header:
a) when linking against "standard" libsqlite3 you must
include the sqlite's own header, usually located on
-/include/sqlite3.h
(no symbol masking applied)
b) and when linking against libspatialite-amalgamation
(intended to be a full libsqlite3 replacement), you
you must include the spatialite's own header, usually
located on -/include/spatialite/sqlite3.h
(this applying symbol masking)
quite obviously, your Open BSD build fails simply because
some QGIS source includes the wrong header file: i.e.
the one corresponding to "standard" libsqlite3, not the
one corresponding to the "private internal copy" supported
by spatialite-internal aka libspatialite-amalgamation.
And I strongly suspect this one being a CMake issue
(inconsistent handling of spatialite-internal)
Anyway, just a final consideration: spatialite-internal is
mainly intended to support Windows. On this o.s. finding
an up-to-date libsqlite.dll is really painful (e.g. the
one shipped by OSGeo4W is really obsolete and useless).
But on any *nix I see many disadvantages (and possible
pitfalls) in using spatialite-internal.
A clean build fully based on standard (external) shared
libraries surely is by far better (and safest).
bye Sandro
#2 Updated by Tim Sutton about 13 years ago
- Target version changed from Version 1.7.1 to Version 1.7.2
#3 Updated by Giovanni Manghi about 13 years ago
- Target version changed from Version 1.7.2 to Version 1.7.3
#4 Updated by Giovanni Manghi about 13 years ago
- Target version changed from Version 1.7.3 to Version 1.7.4
#5 Updated by Giuseppe Sucameli over 12 years ago
- Affected QGIS version set to master
- Crashes QGIS or corrupts data set to No
- Pull Request or Patch supplied set to No
- OS version deleted (
Current)
Is it still valid?
Are you able to build QGis 1.8 (or the latest 1.7.x) on your OpenBSD? Does the build fail with "external" spatialite too?
#6 Updated by Paolo Cavallini over 12 years ago
- Target version changed from Version 1.7.4 to Version 1.8.0
#7 Updated by Paolo Cavallini over 12 years ago
- Target version changed from Version 1.8.0 to Version 2.0.0
#8 Updated by landry Landry Breuil almost 12 years ago
Fwiw, i think is issue can be fixed. I've started porting qgis 1.8.0 to OpenBSD, while here ported systemwide/external spatialite, and qgis 1.8.0 builds fine against it. Since the internal spatialite is dropped in master, i think it wont be an issue in the future.
#9 Updated by Giovanni Manghi almost 12 years ago
- Status changed from Open to Closed
- Resolution set to fixed