Opened 9 years ago

Closed 9 years ago

Last modified 8 years ago

#3281 closed enhancement (fixed)

Avoid exporting symbols in the postgresql module

Reported by: strk Owned by: strk
Priority: medium Milestone: PostGIS 2.1.9
Component: build Version: 2.1.x
Keywords: Cc:

Description

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.

Change History (9)

comment:1 by strk, 9 years ago

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 ?

comment:2 by strk, 9 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
Last edited 9 years ago by strk (previous) (diff)

comment:3 by strk, 9 years ago

Component: postgisbuild/upgrade/install
Owner: changed from pramsey to strk
Status: newassigned

comment:4 by strk, 9 years ago

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

comment:5 by strk, 9 years ago

Milestone: PostGIS 1.5.9PostGIS 2.2.0
Resolution: fixed
Status: assignedclosed
Type: defectenhancement
Version: 1.5.Xtrunk

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 strk, 9 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 strk, 8 years ago

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

comment:8 by strk, 8 years ago

Milestone: PostGIS 2.2.0PostGIS 2.1.9
Version: trunk1.4

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

Last edited 8 years ago by robe (previous) (diff)

comment:9 by robe, 8 years ago

Version: 1.42.1.x

assumed to be a typo.

Last edited 8 years ago by robe (previous) (diff)
Note: See TracTickets for help on using tickets.