Opened 8 years ago
Closed 8 years ago
Last modified 8 years ago
#3281 closed enhancement (fixed)
Avoid exporting symbols in the postgresql module
|Reported by:||strk||Owned by:||strk|
Trying to use system-installed liblwgeom against an older PostGIS version I found that the presence of liblwgeom symbols embedded in the PostgreSQL module messes up usage of the external library.
--exclude-libs ALL to the linker when building postgis.so fixes this issue by avoiding those symbols (those from external libraries) to ever been seen outside of the module.
I'm ticketing this because I'm not sure which systems do or do not support —exclude-libs flag.
Change History (9)
comment:1 by , 8 years ago
comment:2 by , 8 years ago
Avoiding the export slightly reduces library size too (not much, ~1.4%)
-rwxrwxr-x 1 strk src 2319967 Sep 21 16:04 ./postgis/postgis-1.5-allexport.so -rwxrwxr-x 1 strk src 2287199 Sep 21 16:06 ./postgis/postgis-1.5-noexport.so
comment:3 by , 8 years ago
|Component:||postgis → build/upgrade/install|
|Status:||new → assigned|
comment:4 by , 8 years ago
With r14083 I've done this in trunk. It'll only happen when PostGIS is built with a compiler accepting
Broader test is welcome, I'm planning to backport this to 2.1, 2.0 and 1.5
comment:5 by , 8 years ago
|Milestone:||PostGIS 1.5.9 → PostGIS 2.2.0|
|Status:||assigned → closed|
|Type:||defect → enhancement|
|Version:||1.5.X → trunk|
Well, plan changed, I dont' feel comfortable about backporting this. Just in case someone is really using the symbols directly from the postgis module (after all that's how I initially coded the D&P simplification function as an external module…).
For the future, liblwgeom might be used by more modules also dynamically.
comment:6 by , 8 years ago
For the record, I went deep to find the actual problem and here's the result:
[lwin_wkb.c:lwpoint_from_wkb_state:418] calling lwpoint_construct lwpoint_construct from PostGIS 1.5 here
Basically a "lwpoint_from_wkb_state" function from liblwgeom-2.2.0 (dynamically linked) ends up calling "lwpoint_construct" not from itself, but from the liblwgeom version statically linked in the PostGIS-1.5 module loaded by the same PostgreSQL backend process loading the module which dynalinks to liblwgeom-2.2.0.
This is probably due to the fact that the "lwpoint_construct" symbol was resolved before the dynalinking module was even loaded, so it was found in the process at the time of lookup.
In turn, this explains why _omitting_ to export the statically-linked symbols from PostGIS-1.5 fixes the issue.
Statically linking liblwgeom in the new module also fixes the issue because there's no runtime linking involved in calling all those functions (I think).
These findings may be of interest for @darkblue_b
comment:7 by , 8 years ago
NOTE: I've backported the "no-export-symbols" to the 2.1 branch (2.1.9) with r14151
comment:8 by , 8 years ago
|Milestone:||PostGIS 2.2.0 → PostGIS 2.1.9|
|Version:||trunk → 1.4|
Hmm why did the version of this ticket get switched to 1.4 (a branch we haven't touched in ages.).
comment:9 by , 8 years ago
|Version:||1.4 → 2.1.x|
assumed to be a typo.
A pull request is under testing here: https://github.com/postgis/postgis/pull/65 (for 1.5 branch) Can anyone test it on windows/osx/*bsd or with non GNU linker ?