[Mapguide-trac] [mapguide-trac] #2874: Error on MgMappingUtil.StylizeLayers

[MapGuide Open Source]

#2874: Error on MgMappingUtil.StylizeLayers
----------------------+----------------------
 Reporter:  dfanetti  |        Owner:  (none)
     Type:  defect    |       Status:  new
 Priority:  low       |    Milestone:
Component:  General   |      Version:
 Severity:  trivial   |   Resolution:
 Keywords:            |  External ID:
----------------------+----------------------
Comment (by jng):

 This is more a mental note for myself when I finally give this ticket my
 full attention:

 My current running theory is that due to our linux builds of both MapGuide
 and FDO not using [https://gcc.gnu.org/wiki/Visibility GCC symbol
 visibility] (`-fvisibility=hidden`), symbols of thirdparty libs we use
 (such as SQLite) are present in our final `.so` files. You can see
 `sqlite3_*` symbols when doing a symbol dump of  some of our `.so` files.

 Because these symbols are present, I theorize that when GDAL calls PROJ
 for any CS/projection functionality, PROJ's use of SQLite is hitting our
 `.so` files for SQLite3 symbols instead of the normal expected SQLite3
 `.so` library and this "crossing of the wires" is the cause of the
 reported error:

 `PROJ: SQLite3 version is 3.3.17, whereas at least 3.11 should be used`

 We had this "crossing of the wires" issue in the past with the SDF
 provider (looking for sqlite3 functions in the DWF Toolkit .so), but we
 were able to band-aid over this problem by building the SDF provider with
 `-BSymbolic`, forcing the SDF provider to look within itself for SQLite3
 functions.

 That kind of band-aid won't work here, we need to make these sqlite3
 symbols hidden and GCC visibility attributes would be the proper way to
 make sure this happens.

 But I don't see adding GCC visibility attributes to MapGuide/FDO to be a
 trivial task. While conceptually similar to `__declspec(dllimport)` and
 `__declspec(dllexport)` on Windows, we have to make sure the proper pre-
 preprocessor symbols are added to all the MapGuide/FDO projects so that we
 are properly exporting and importing any given public API (just like on
 Windows).

 And that's a lot of projects we have to update!

 Another less nuclear option (we only just want to hide our internal
 sqlite3 symbols!) may be something like this:

 https://stackoverflow.com/questions/61598075/hide-symbols-from-a-3rd-
 party-a-file-that-is-linked-into-a-so-file
-- 
Ticket URL: <https://trac.osgeo.org/mapguide/ticket/2874#comment:9>
MapGuide Open Source <http://mapguide.osgeo.org/>
MapGuide Open Source Internals