Give help when facing 'Cannot load extension'

[3nids]

see #6

[strk]

Interesting, looks like a new dependency was added to liblwgeom w/out proper linking, are you up to file a ticket upstream ? liblwgeom.so ships with a call to an undefined function even when not configured to use it.

[strk]

Note that building fineltra against a dynamic liblwgeom would only result in a sane environment IFF PostGIS is also linked to liblwgeom dynamically, which is NOT the case by default (but might be when installed via some Debian packages)

[3nids]

This is a bit beyond my understanding...Might be better phrased if you file the ticket on your side. Sorry, not that I don't want to collaborate, I just don't feel confident enough

[strk]

If I read things correctly, the missing symbol comes from a new enough proj library, was libproj linked in your build ? Which version ?

[3nids]

ldd /usr/lib/postgresql/9.5/lib/fineltra-0.0.so
returns

linux-vdso.so.1 => (0x00007ffd959e0000)
liblwgeom-2.2.so.5 => /usr/lib/liblwgeom-2.2.so.5 (0x00007fca8d67c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fca8d2b3000)
libgeos_c.so.1 => /usr/lib/x86_64-linux-gnu/libgeos_c.so.1 (0x00007fca8d084000)
libproj.so.9 => /usr/lib/x86_64-linux-gnu/libproj.so.9 (0x00007fca8ce29000)
libjson-c.so.2 => /lib/x86_64-linux-gnu/libjson-c.so.2 (0x00007fca8cc1e000)
libSFCGAL.so.1 => /usr/lib/x86_64-linux-gnu/libSFCGAL.so.1 (0x00007fca8c1b2000)
/lib64/ld-linux-x86-64.so.2 (0x000055b1f3ab7000)
libgeos-3.5.0.so => /usr/lib/x86_64-linux-gnu/libgeos-3.5.0.so (0x00007fca8be18000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fca8ba96000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fca8b87f000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fca8b662000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fca8b359000)
libCGAL.so.11 => /usr/lib/x86_64-linux-gnu/libCGAL.so.11 (0x00007fca8b131000)
libCGAL_Core.so.11 => /usr/lib/x86_64-linux-gnu/libCGAL_Core.so.11 (0x00007fca8aef9000)
libmpfr.so.4 => /usr/lib/x86_64-linux-gnu/libmpfr.so.4 (0x00007fca8ac94000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fca8aa13000)
libosgDB.so.100 => /usr/lib/x86_64-linux-gnu/libosgDB.so.100 (0x00007fca8a70f000)
libosg.so.100 => /usr/lib/x86_64-linux-gnu/libosg.so.100 (0x00007fca8a238000)
libboost_thread.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.58.0 (0x00007fca8a011000)
libboost_system.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0 (0x00007fca89e0d000)
libboost_serialization.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_serialization.so.1.58.0 (0x00007fca89bac000)
libosgUtil.so.100 => /usr/lib/x86_64-linux-gnu/libosgUtil.so.100 (0x00007fca897e9000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fca895e5000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fca893ca000)
libOpenThreads.so.20 => /usr/lib/x86_64-linux-gnu/libOpenThreads.so.20 (0x00007fca891c2000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fca88fba000)
libGL.so.1 => /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 (0x00007fca88d48000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007fca88b1f000)
libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0 (0x00007fca8891b000)
libxcb-present.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-present.so.0 (0x00007fca88718000)
libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1 (0x00007fca88511000)
libxshmfence.so.1 => /usr/lib/x86_64-linux-gnu/libxshmfence.so.1 (0x00007fca8830d000)
libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007fca880df000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007fca87ecd000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007fca87cc9000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007fca87ac3000)
libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007fca878c1000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007fca87586000)
libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 (0x00007fca8736d000)
libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0 (0x00007fca87168000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fca86f45000)
libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007fca86d3f000)
libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007fca86b30000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fca8692b000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fca86725000)

and ldconfig returns

libproj.so.9 -> libproj.so.9.1.0

[strk]

What does this return: ``` nm /usr/lib/x86_64-linux-gnu/libproj.so.9 | grep geod_ ```

[3nids]

nm: /usr/lib/x86_64-linux-gnu/libproj.so.9: no symbols

not really good, is it?

[strk]

Try adding --dynamic to the call

[3nids]

0000000000044300 T geod_direct
0000000000044190 T geod_gendirect
0000000000044330 T geod_geninverse
00000000000430d0 T geod_genposition
0000000000042320 T geod_init
0000000000047420 T geod_inverse
0000000000042950 T geod_lineinit
0000000000047600 T geod_polygon_addedge
0000000000047490 T geod_polygon_addpoint
0000000000048000 T geod_polygonarea
00000000000476f0 T geod_polygon_compute
0000000000047440 T geod_polygon_init
0000000000047d20 T geod_polygon_testedge
00000000000479a0 T geod_polygon_testpoint
0000000000044160 T geod_position

[strk]

Ok so next question is how did you build liblwgeom, as it looks like it was built against a newer proj4 version

[3nids]

installed from ubuntugis-unstable

[strk]

Was proj4 installed from the same repo ? In that case it looks like a package bug...

[3nids]

Sorry, both came from us.archive.ubuntu.com_ubuntu_dists_xenial_universe_binary-amd64_Packages

After re-enabling ubuntusgis, liproj-dev is still the same 4.9.2-2, while liblwgeom came from ubuntugis as 2.2.1+dfsg-3~xenial0.
Anyway, the error is still the same.

I would propose to have the helpl in the README, what do you think?

[strk]

geod_polygon_addpoint symbol is actually found in the proj4 library, according to #8 (comment), so I'd really like to know why the symbol isn't found when liblwgeom is linked statically while it is when it is linked dynamically...

If you leave a link to this issue in the README section I'll merge but we'd really want this fixed more than worked around. Maybe it's just a matter of linking line ordering.