Avoid exporting symbols in the postgresql module

[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.

Passing --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.

[strk]

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 ?

[strk]

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

[strk]

With r14083 I've done this in trunk. It'll only happen when PostGIS is built with a compiler accepting -Wl,--exclude-libs,ALL Broader test is welcome, I'm planning to backport this to 2.1, 2.0 and 1.5

[strk]

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.

[strk]

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

[strk]

NOTE: I've backported the "no-export-symbols" to the 2.1 branch (2.1.9) with r14151

[strk]

Hmm why did the version of this ticket get switched to 1.4 (a branch we haven't touched in ages.).

[robe]

assumed to be a typo.