fake-name/pg-spgist_hamming

Error in Make in function bktree_inner_consistent

gregdan3 opened this issue · 3 comments

gregdan3 commented

Version Information

PostgreSQL 10.6
gcc 4.8.5
CentOS 7, running Linux 3.10.0

Steps to Reproduce

  1. git clone https://github.com/fake-name/pg-spgist_hamming.git
  2. cd pg-spgist_hamming/bktree
  3. make

Make then outputs the following:

gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -DLINUX_OOM_SCORE_ADJ=0 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -fPIC -I. -I. -I/usr/include/pgsql/server -I/usr/include/pgsql/internal -D_GNU_SOURCE -I/usr/include/libxml2   -c -o bktree.o bktree.c
bktree.c: In function ‘bktree_inner_consistent’:
bktree.c:193:9: error: ‘RTLeftStrategyNumber’ undeclared (first use in this function)
    case RTLeftStrategyNumber:
         ^
bktree.c:193:9: note: each undeclared identifier is reported only once for each function it appears in
bktree.c:228:9: error: ‘RTOverLeftStrategyNumber’ undeclared (first use in this function)
    case RTOverLeftStrategyNumber:
         ^
bktree.c: In function ‘bktree_leaf_consistent’:
bktree.c:272:9: error: ‘RTLeftStrategyNumber’ undeclared (first use in this function)
    case RTLeftStrategyNumber:
         ^
bktree.c:295:9: error: ‘RTOverLeftStrategyNumber’ undeclared (first use in this function)
    case RTOverLeftStrategyNumber:
         ^
bktree.c: At top level:
bktree.c:339:1: warning: no previous prototype for ‘bktree_eq_match’ [-Wmissing-prototypes]
 bktree_eq_match(PG_FUNCTION_ARGS)
 ^
make: *** [bktree.o] Error 1

This is possibly related to the fact that pg_config is referring to postgres 9.2.23, which is one of the previous postgres version we had. Doesn't seem to have been correctly updated.

Still investigating; figured I'd post this here for any advice I can get.

Quick update, I tested this on my own system running the following:
PostgreSQL 10.4 (I had PostgreSQL 11.5 before, and downgraded to better match my server; pg_config does not reflect this downgrade, however, still reporting 11.5)
gcc 9.2.0
Archlinux running Kernel 5.3.7

The directory referred to is /usr/include/pgsql/... on my server. Just a name change; admittedly not sure why. But the compile flags DO refer to this directory correctly, so I'm still lost as to why this is not defined.

So, maybe useful discovery! The missing definitions are in in server/access/gist.h on my server, but on my personal device they're in server/access/stratnum.h.

I don't actually know why this doesn't work, however. As far as I'm aware, it should, since the entire parent directory is being included.

It's also worth noting that /usr/include/libxml2 is included, and was not previously installed. Strange, but not a problem.

Last update. I was digging around and discovered two things.

  1. The fix is to refer to the correct pg_config binary, in the actual location postgres 10 was installed.
  2. I promptly discovered right after this that the admin before me had not installed postgres-devel, so for the time being, we cannot use this tool.

I'm gonna go ahead and close this; I suspect the issue will be resolved after correcting both of these things.

fake-name commented

Heh, yeah, it sounds like build issues.

You definitely need to make sure that the output of pg_config is correct for the postgres instance you're trying to build things for.

It'd probably be worth checking you can build something from pgxn to validate your infrastructure is sane.

gregdan3 commented

Thanks for the advice!

I actually did manage to get it working after installing postgres10-devel! The problem I dealt with was not realizing how important the output of pg_config was.

The specific fix was to specify the correct pg_config binary directly in the Makefile.

Thank you so much for your work. This is fantastic, and a far faster solution than anything we had come up with previously.

fake-name commented

Great to hear you got it working! For what it's worth, there's a lot of optimization room in the current implementation. It's ~33% as fast as a somewhat optimized pure-C++ implementation (python wrapper here).

Basically, the mapping of a BK-tree structure to the way a SP-GiST index works means there's a extra layer of indirection that's not needed for proper operation. It'd be better to write the index as a pure GiST index (or even a native index without using GiST at all), but doing so is considerably more challenging.

I pretty regularly go "I should revisit that", and then get distracted by other projects and don't do anything. Ugh.

It's not pg_config that's specifically important, it's having the postgres build tooling working for the correct server version that's the important part. Admittedly, postgres solves this problem with the pg_config tool, but you could very well set the environment variables it generates manually (though that'd be a lot of work).

Effectively, almost all C postgres extensions operate by being compiled for the target server instance. It's fairly uncommon to distribute them as compiled binaries.