Opened 4 years ago

Closed 4 years ago

Last modified 3 years ago

#4474 closed defect (fixed)

bessie32 FreeBSD12 32-bit wagyu compile causes undefined symbol error

Reported by: robe Owned by: robe
Priority: blocker Milestone: Website Management, Bots
Component: QA/buildbots Version: 2.5.x -- EOL
Keywords: Cc:


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/": dlopen (/usr/local/lib/postgresql/ failed: /usr/local/lib/postgresql/ 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.

Change History (22)

comment:1 by robe, 4 years ago

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

comment:2 by robe, 4 years ago

In 17683:

Put libiconv back evidentally still need that one
References #4474

comment:3 by robe, 4 years ago

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.

comment:4 by pramsey, 4 years ago

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.

Maybe include a newer c++ runtime dll?

comment:5 by pramsey, 4 years ago

Other tickets point to a mixed up build environment as a source of the issue.

comment:6 by robe, 4 years ago

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.

comment:7 by Algunenano, 4 years ago

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

comment:8 by robe, 4 years ago

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

comment:9 by robe, 4 years ago

Milestone: PostGIS 3.0.0Management 2.0

comment:10 by robe, 4 years ago

Well this sucks. I built a new bessie32 from FreeBSD 12 image 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

comment:11 by robe, 4 years ago

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.

comment:12 by robe, 4 years ago

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

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.

comment:13 by robe, 4 years ago

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.

comment:14 by robe, 4 years ago

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

comment:15 by robe, 4 years ago

Summary: bessie32 failingbessie32 FreeBSD12 32-bit wagyu compile causes undefined symbol error

comment:16 by Algunenano, 4 years ago

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.

comment:17 by robe, 4 years ago

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


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 case 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
Last edited 4 years ago by robe (previous) (diff)

comment:18 by robe, 4 years ago

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

comment:19 by robe, 4 years ago

In 17837:

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

comment:20 by robe, 4 years ago

The above sadly still failed with same error, even though it shows it's using gcc8 in both cases now.

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

comment:21 by robe, 4 years ago

Resolution: fixed
Status: newclosed

In 17838:

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

comment:22 by robe, 3 years ago

Milestone: Management 2.0Website Management, Bots

Milestone renamed

Note: See TracTickets for help on using tickets.