#4260 closed enhancement (fixed)
Stop installing headers
Reported by: | Algunenano | Owned by: | Algunenano |
---|---|---|---|
Priority: | blocker | Milestone: | PostGIS 3.0.0 |
Component: | liblwgeom | Version: | master |
Keywords: | Cc: |
Description
02:22:50 psql:/usr/home/jenkins/workspace/PostGIS_Worker_Run/label/bessie32/e90f4dcfde28ab68e70c38fc761960a2060f82fa/regress/00-regress-install/share/contrib/postgis/rtpostgis.sql:129: ERROR: could not load library "/usr/home/jenkins/workspace/PostGIS_Worker_Run/label/bessie32/e90f4dcfde28ab68e70c38fc761960a2060f82fa/regress/00-regress-install/lib/rtpostgis-3.so": dlopen (/usr/home/jenkins/workspace/PostGIS_Worker_Run/label/bessie32/e90f4dcfde28ab68e70c38fc761960a2060f82fa/regress/00-regress-install/lib/rtpostgis-3.so) failed: /usr/home/jenkins/workspace/PostGIS_Worker_Run/label/bessie32/e90f4dcfde28ab68e70c38fc761960a2060f82fa/regress/00-regress-install/lib/rtpostgis-3.so: Undefined symbol "lwgeom_is_empty"
lwgeom_is_empty is located in "lwinline.h" which I guess should be installed too as it's included by "liblwgeom.h"
Change History (18)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
Even better question: do we need to install headers at all, if liblwgeom is our private thing?
comment:3 by , 6 years ago
This looks more like using installed version of liblwgeom instead of the one in the tree, as it started showing only after bessie started building older branches.
I think you are right, rt_pg/Makefile
is including LIBLWGEOM_CFLAGS after the rest of the CFLAGS
but it should be included first.
Even better question: do we need to install headers at all, if liblwgeom is our private thing?
AFAIK liblwgeom
isn't "our private thing" and it's used by external projects. Those projects will need lwinline.h
too.
comment:4 by , 6 years ago
Priority: | medium → blocker |
---|---|
Summary: | FreeBSD failures → Stop installing headers |
I've changed this ticket to stop installing headers.
comment:10 by , 6 years ago
yeh finally :)
I'll take out my local patch and see if it still builds statically.
comment:11 by , 6 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Statically link shp2pgsql and other loader utilities to
liblwgeom References #4260
Travis didn't like this (https://travis-ci.org/postgis/postgis/jobs/482789301, libtool 2.4.6) but I'm not sure why; it works fine in my system with similar releases (libtool 2.4.6, clang 7 or gcc 8.2):
libtool: link: gcc -I ../liblwgeom -Wall -Wmissing-prototypes -std=gnu99 -g -O2 -fno-math-errno -fno-signed-zeros -fPIC -DPIC shpopen.o dbfopen.o getopt.o shpcommon.o safileio.o pgsql2shp-core.o pgsql2shp-cli.o -Wl,--as-needed -Wl,-rpath -Wl,/usr/local/pgsql/lib -Wl,--enable-new-dtags -o pgsql2shp ../liblwgeom/.libs/liblwgeom.a -L/usr/local/lib /usr/local/lib/libgeos_c.a /usr/local/lib/libgeos.a /usr/local/lib/libproj.a -lpthread -ljson-c -lm /usr/local/lib/libSFCGAL.so -L/usr/local/pgsql/lib -lc -lpq libtool: link: gcc -I ../liblwgeom -Wall -Wmissing-prototypes -std=gnu99 -g -O2 -fno-math-errno -fno-signed-zeros -fPIC -DPIC shpopen.o dbfopen.o getopt.o shpcommon.o safileio.o shp2pgsql-core.o shp2pgsql-cli.o -o shp2pgsql -Wl,--as-needed -Wl,-rpath -Wl,/usr/local/pgsql/lib -Wl,--enable-new-dtags ../liblwgeom/.libs/liblwgeom.a -L/usr/local/lib /usr/local/lib/libgeos_c.a /usr/local/lib/libgeos.a /usr/local/lib/libproj.a -lpthread -ljson-c -lm /usr/local/lib/libSFCGAL.so -L/usr/local/pgsql/lib -lc /usr/bin/ld: /usr/local/lib/libgeos_c.a(libgeos_c_la-geos_ts_c.o): in function `GEOS_init_r': /src/geos/capi/geos_ts_c.cpp:340: undefined reference to `operator new(unsigned long)' /usr/bin/ld: /usr/local/lib/libgeos_c.a(libgeos_c_la-geos_ts_c.o): in function `GEOSWKBReader_destroy_r': /usr/include/c++/8/ext/new_allocator.h:125: undefined reference to `operator delete(void*)' /usr/bin/ld: /usr/local/lib/libgeos_c.a(libgeos_c_la-geos_ts_c.o): in function `GEOSRelate_r':
comment:12 by , 6 years ago
yap seems none of the docker bots (dronie for example) were happy with this change.
comment:13 by , 6 years ago
I think r17208 fixes it; at least it works for me locally and also passes Travis. We'll see how other bots behave.
comment:15 by , 6 years ago
I feel that the logical step after this is to simply not build the dynamic liblwgeom
library (liblwgeom.so). That should make the build faster and break any internal library/binary that still depends on it. I'll get to it.
comment:17 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Type: | defect → enhancement |
This seems to be working in all bots now, except Gitlab-CI which is broken because it has an old GEOS.
As a side note, and I guess @robe will be interested, if compiled with Link Time Optimization (I'm using -flto=thin
) the loader binaries shp2pgsql
and pgsql2shp
won't depend on either GEOS, PROJ or the c++ runtime:
$ ldd /usr/bin/shp2pgsql linux-vdso.so.1 (0x00007ffde4f33000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f0ec9943000) libm.so.6 => /usr/lib/libm.so.6 (0x00007f0ec97be000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f0ec9b24000) $ ldd /usr/bin/pgsql2shp linux-vdso.so.1 (0x00007fff01321000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f44186d5000) libpq.so.5 => /usr/lib/libpq.so.5 (0x00007f4418683000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f44188b5000) libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x00007f44185f3000) libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x00007f4418321000) libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00007f44180d3000) libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 (0x00007f441807f000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f441805c000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f441801e000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00007f4417d35000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00007f4417b02000) libcom_err.so.2 => /usr/lib/libcom_err.so.2 (0x00007f4417afc000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00007f44178ef000) libkeyutils.so.1 => /usr/lib/libkeyutils.so.1 (0x00007f44178e6000) libresolv.so.2 => /usr/lib/libresolv.so.2 (0x00007f44178cd000) liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0x00007f44178bc000) libsasl2.so.3 => /usr/lib/libsasl2.so.3 (0x00007f441789e000)
raster2pgsql
is a different beast as it depends on basically the whole world :D
comment:18 by , 2 years ago
For the record, the -static
switch was removed in [93b98069713d46282cd23c3bedec6fc82242a513/git]
everything in lwinline is inlined on compile time. even if it wasn't, link-time dependencies aren't done via .h files install.
This looks more like using installed version of liblwgeom instead of the one in the tree, as it started showing only after bessie started building older branches.