Opened 3 years ago

Closed 3 years ago

#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 (17)

comment:1 Changed 3 years ago by komzpa

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.

comment:2 Changed 3 years ago by komzpa

Even better question: do we need to install headers at all, if liblwgeom is our private thing?

comment:3 Changed 3 years ago by Algunenano

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 Changed 3 years ago by robe

Priority: mediumblocker
Summary: FreeBSD failuresStop installing headers

I've changed this ticket to stop installing headers.

comment:5 Changed 3 years ago by Raul Marin

In 17084:

Include liblwgeom first

Ported from r16813 (2.5)
References #4180
References #4260

comment:7 Changed 3 years ago by komzpa

Resolution: fixed
Status: assignedclosed

In 17098:

Don't install liblwgeom.

Closes https://github.com/postgis/postgis/pull/348
Closes #4260

comment:8 Changed 3 years ago by komzpa

In 17099:

Build process needs presence of install: and uninstall: targets

References #4260

comment:9 Changed 3 years ago by pramsey

In 17202:

Statically link shp2pgsql and other loader utilities to
liblwgeom
References #4260

comment:10 Changed 3 years ago by robe

yeh finally :)

I'll take out my local patch and see if it still builds statically.

comment:11 Changed 3 years ago by Algunenano

Resolution: fixed
Status: closedreopened

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 Changed 3 years ago by robe

yap seems none of the docker bots (dronie for example) were happy with this change.

comment:13 Changed 3 years ago by Algunenano

I think r17208 fixes it; at least it works for me locally and also passes Travis. We'll see how other bots behave.

comment:14 Changed 3 years ago by Raul Marin

In 17209:

Build raster loader with static liblwgeom too

References #4260

comment:15 Changed 3 years ago by Algunenano

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:16 Changed 3 years ago by Raul Marin

In 17211:

Only build static liblwgeom

References #4260
Closes https://github.com/postgis/postgis/pull/366

comment:17 Changed 3 years ago by Algunenano

Resolution: fixed
Status: reopenedclosed
Type: defectenhancement

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

Note: See TracTickets for help on using tickets.