bessie32 FreeBSD12 32-bit wagyu compile causes undefined symbol error

[robe]

Looks like I managed to break bessie32 by upgrading her. She's now at proj 6.1, GDAL 2.4.2 and before was at proj 5.1 (or 4.9.3) can't remember.

Now she's showing this error:

18:27:49  failed (Error encountered creating EXTENSION POSTGIS: /home/jenkins/tmp/pgis_reg_ac1fee0e6516cc0c991e7697c501c730d008b030/regress_log)
18:27:49 -----------------------------------------------------------------------------
18:27:49 ERROR:  could not load library "/usr/local/lib/postgresql/postgis-3.so": dlopen (/usr/local/lib/postgresql/postgis-3.so) failed: /usr/local/lib/postgresql/postgis-3.so: Undefined symbol "_ZNKSt8__detail20_Prime_rehash_policy11_M_next_bktEj"
18:27:49 -----------------------------------------------------------------------------

Have no clue what library would be triggering that.

I'm going to get rid of the configure line for proj that is still in there which it warns should be taken out and hopefully that will fix it.

[robe]

In 17681:

Try to fix bessie32 Undefined symbol "_ZNKSt8detail20_Prime_rehash_policy11_M_next_bktEj" by getting rid of redundant configure lines that should be pulled in via pkg-config
References #4474 for PostGIS 3.0

[robe]

In 17683:

Put libiconv back evidentally still need that one
References #4474

[robe]

okay all that didn't help, but seems it's only the 3.0 failing with this error. 2.5 run is fine and 2.4/2.3 aside from the same old 32-bit regress failures/differences.

[pramsey]

Well, that missing symbol seems to come from libstdc++, so the fact that you're missing it would seem to imply that one of the DLLs you're including was compiled against a C++ library that is newer/fancier than the one you're bundling into your build.

​https://gcc.gnu.org/onlinedocs/gcc-4.8.1/libstdc++/api/a00533.html

Maybe include a newer c++ runtime dll?

[pramsey]

Other tickets point to a mixed up build environment as a source of the issue. ​https://github.com/rust-lang/rust/issues/14404

[robe]

I'm in the middle of upgrading to FreeBSD 11.3 and FreeBSD 12.0 since 11.2 is close to EOL. So now things are a bit of a royal mess at the moment.

[Algunenano]

Just a note: Both bessie and Bessie32 are currently offline.

[robe]

yah I know haven't had a chance to revisit the issue. I think I took them out of the run jobs

[robe]

Well this sucks. I built a new bessie32 from FreeBSD 12 image ​https://download.freebsd.org/ftp/releases/VM-IMAGES/12.0-RELEASE/i386/Latest/FreeBSD-12.0-RELEASE-i386.vmdk.xz(date DEC 2018)

(compared to upgrading the FreeBSD 11 install) and to my disappointment, it ended in the same error after I was done installing everything.

What I don't understand is why everything works fine in PostGIS 2.5. As I recall PostGIS 2.5 compiles and regresses fine (aside from the known 32-bit freebsd issues).

Only thing I can think of is maybe our reliance now on pkg-config or that our special source for using new Proj 6 features is bringing something else in that PostgreSQL doesn't like.

Note that in 2.5 - gdal is the same, proj is the same, geos is the same, and PostgreSQL is the same

[robe]

If the bessie 64-bit experiment works better using portsnap, I'll use that instead of using the binary install approach. Just that portsnap is so painfully slow since it compiles all the gdal dependencies and I was stupid enought to check -- yah I want netcdf and popler and curl. Maybe I shouldn't have gone so shopping cart crazy.

[robe]

Getting back to your idea about the 2 different compilers being incompatible, I noticed this and wagyu is new in 3.0, which would explain why it might not be an issue in 2.5

 -------------- Compiler Info ------------- 
18:17:03   C compiler:           gcc -std=gnu99 -g -O2 -fno-math-errno -fno-signed-zeros
18:17:03   C++ compiler (Wagyu): gcc8 -std=c++11 -x c++ 
18:17:03   CPPFLAGS:              -I/usr/local/include -I/usr/local/include  -I/usr/local/include  -I/usr/local/include/libxml2 -I/usr/include -I/usr/local/include -I/usr/local/include/json-c  -I/usr/local/include  
18:17:03   SQL preprocessor:     /usr/bin/cpp -traditional-cpp -w -P
18:17:03 

On FreeBSD 12 64 bit which doesn't have the issue, it has this:

10:14:07   C compiler:           cc -std=gnu99 -g -O2 -fno-math-errno -fno-signed-zeros
10:14:07   C++ compiler (Wagyu): cc -std=c++11 -x c++ 

so looks like the 32-bit is using a different compiler for wagyu for some reason.

At anyrate I'm testing now turning off wagyu to see if it solves the issue.

[robe]

Confirmed -- got past if I disable wagyu. I'm going to disable on the 32-bit for now until we figure out a better solution.

[robe]

In 17829:

Turn off wagyu for now for 32-bit FreeBSD12. For some reason it is deciding to use a higher gcc for wagyu building which causes the issue
References #4474

[Algunenano]

so looks like the 32-bit is using a different compiler for wagyu for some reason.

Wagyu is built with the same compiler as the extension, that is pg_config --cc, so you've probably built PG with gcc8 and the rest of the dependencies with gcc.

[robe]

I didn't build PG. PG I got from

pkg install postgresql

I always thought the rest of postgis would use the same. I wonder if this is a similar issue to winnie. To get around winnie's issue, I just did

LDFLAGS="-Wl,--enable-auto-import...

winnie has below though I assumed gcc = x86_64-w64-mingw32-gcc are just aliases for one another. Why it chooses one name in one can and another in another seems a bit odd though

------------- Compiler Info ------------- 
  C compiler:           x86_64-w64-mingw32-gcc -std=gnu99 -g -O2 -fno-math-errno -fno-signed-zeros
  C++ compiler (Wagyu): gcc -std=c++11 -x c++ 
  CPPFLAGS:              -IE:/jenkins/geos/rel-3.8w64gcc81/include -I/projects/proj/rel-5.2.0w64gcc81/include -IE:/jenkins/protobuf/rel-3.2.0w64gcc81/include   -I/projects/libxml/rel-libxml2-2.9.9w64gcc81/include/libxml2 -I/projects/CGAL/rel-sfcgal-1.3.2w64gcc81/include -IE:/jenkins/json-c/rel-0.12w64gcc81/include/json-c   -IE:/jenkins/pcre/rel-8.33w64gcc81/include   
  SQL preprocessor:     /mingw64/bin/cpp -traditional-cpp -w -P

[robe]

Confirmed the 32-bit bessie postgresql is compiled with gcc8.

Though I would think the issue would then be with the rest of PostGIS proper and not wagyu.

21:46:40 PostgreSQL 11.5 on i386-portbld-freebsd12.0, compiled by gcc8 (FreeBSD Ports Collection) 8.3.0, 32-bit

[robe]

In 17837:

Put back wagyu, but try to force gcc8 as compiler and use CFLAGS from PostgreSQL 11 install
References #4474

[robe]

The above sadly still failed with same error, even though it shows it's using gcc8 in both cases now. ​https://debbie.postgis.net/view/PostGIS/job/PostGIS_Worker_Run/label=bessie32/1498/consoleFull

12:41:54 
12:41:54  -------------- Compiler Info ------------- 
12:41:54   C compiler:           gcc8 -std=gnu99 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-trunc -fno-math-errno -fno-signed-zeros
12:41:54   C++ compiler (Wagyu): gcc8 -std=c++11 -x c++ 
12:41:54   CPPFLAGS:              -I/usr/local/include -I/usr/local/include  -I/usr/local/include  -I/usr/local/include/libxml2 -I/usr/include -I/usr/local/include -I/usr/local/include/json-c  -I/usr/local/include  
12:41:54   SQL preprocessor:     /usr/bin/cpp -traditional-cpp -w -P

[robe]

In 17838:

Add CXX and CXXFLAGS from pg_config seems to fix wagyu load issue
Closes #4474

[robe]

Milestone renamed