Bug report #4030

1.7.0 Build failure with internal spatialite on OpenBSD

Added by landry Landry Breuil over 13 years ago. Updated over 11 years ago.

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.

patch-src_core_spatialite_sqlite3_c - put the #define list within #ifndef __OpenBSD__ (719 Bytes) landry Landry Breuil, 2011-06-29 03:05 AM

patch-src_core_spatialite_spatialite_c - put the #define list within #ifndef __OpenBSD__ (753 Bytes) landry Landry Breuil, 2011-06-29 03:05 AM

patch-src_core_spatialite_headers_spatialite_sqlite3_h - put the #define list within #ifndef __OpenBSD__ (697 Bytes) landry Landry Breuil, 2011-06-29 03:05 AM

patch-src_core_spatialite_headers_spatialite_sqlite3ext_h - put the #define list within #ifndef __OpenBSD__ (703 Bytes) landry Landry Breuil, 2011-06-29 03:05 AM

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 almost 13 years ago

  • Target version changed from Version 1.7.2 to Version 1.7.3

#4 Updated by Giovanni Manghi almost 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 about 12 years ago

  • Target version changed from Version 1.8.0 to Version 2.0.0

#8 Updated by landry Landry Breuil over 11 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 over 11 years ago

  • Status changed from Open to Closed
  • Resolution set to fixed

Also available in: Atom PDF