IF someone tries to use security/krb5 to stay MIT or security/heimdal to get a newer version of heimdal postgresql is one of packages that wouldn't work anymore out of the box. So we have: 1. World WITHOUT_KERBEROS and WITHOUT_KERBEROS_SUPPORT. 2. Trying to build postgresql server. Here we go down: configure:3851: $? = 1 configure:3871: checking whether the C compiler works configure:3893: clang60 -O3 -pipe -march=native -O3 -funroll-loops -fstack-protector -fno-strict-aliasing -I/usr/local/include -L/usr/local/lib -lpthread -lgssapi -L/usr/local/lib -Wl,-rpath,/usr/local/lib -fstack-protector conftest.c > &5 /usr/local/bin/ld: cannot find -lgssapi This happens because: - security/krb5 provides libgssapi_krb5 in /usr/local/lib (missed); - security/heimdal provides libgssapi in /usr/local/lib/heimdal (not included in -L) Here's an example how this can be solved (I'm not good with options so this is just to show the concept): OPTIONS_RADIO+= GSSAPI OPTIONS_RADIO_GSSAPI= GSSAPI_HEIMDAL GSSAPI_MIT .if exists(/usr/lib/libgssapi.so) # ? didn't have it installed OPTIONS_RADIO_GSSAPI+= GSSAPI_BASE OPTIONS_DEFAULT+= GSSAPI_BASE GSSAPI_BASE_USES= gssapi:base GSSAPI_BASE_CONFIGURE_ON= --with-gssapi .endif GSSAPI_HEIMDAL_USES= gssapi:heimdal,flags GSSAPI_HEIMDAL_CONFIGURE_ON= --with-gssapi GSSAPI_HEIMDAL_CFLAGS+= -I/usr/local/include/heimdal GSSAPI_HEIMDAL_LDLAGS+= -L/usr/local/lib/heimdal GSSAPI_HEIMDAL_LIB_DEPENDS+= libgssapi.so:security/heimdal GSSAPI_MIT_USES= gssapi:mit GSSAPI_MIT_CONFIGURE_ON= --with-gssapi GSSAPI_MIT_CFLAGS+= -I/usr/local/include GSSAPI_MIT_LDLAGS+= -L/usr/local/lib GSSAPI_MIT_LIB_DEPENDS+= libgssapi_krb5.so:security/krb5 .endif Hope this helps a little.
MIT KRB5 has no libgssapi. It is libgssapi_krb5. libgssapi is available in base and in the heimdal port. Having said that, on my laptop I am able to successfully build postgres95-server: stage/usr/local/bin/pg_upgrade' gmake[3]: Leaving directory '/export/wrkdir/amd64/export/home/cy/freebsd/svn/ports/databases/postgresql95-server/work/postgresql-9.5.11/src/bin/pg_upgrade' gmake[2]: Leaving directory '/export/wrkdir/amd64/export/home/cy/freebsd/svn/ports/databases/postgresql95-server/work/postgresql-9.5.11/src/bin/pg_upgrade' ====> Compressing man pages (compress-man) ===> Staging rc.d startup script(s) slippy$ slippy$ env | grep -i ports PWD=/home/cy/freebsd/svn/ports/databases/postgresql95-server PORT_DBDIR=/home/cy/freebsd/db/ports PORTSDIR=/home/cy/freebsd/svn/ports slippy$ cat ~/freebsd/db/ports/databases_postgresql95-server/options # This file is auto-generated by 'make config'. # Options for postgresql95-server-9.5.11 _OPTIONS_READ=postgresql95-server-9.5.11 _FILE_COMPLETE_OPTIONS_LIST=DEBUG DTRACE GSSAPI ICU INTDATE LDAP NLS OPTIMIZED_CFLAGS PAM SSL TZDATA XML OPTIONS_FILE_UNSET+=DEBUG OPTIONS_FILE_UNSET+=DTRACE OPTIONS_FILE_SET+=GSSAPI ^^^^^^ OPTIONS_FILE_UNSET+=ICU OPTIONS_FILE_SET+=INTDATE OPTIONS_FILE_UNSET+=LDAP OPTIONS_FILE_SET+=NLS OPTIONS_FILE_UNSET+=OPTIMIZED_CFLAGS OPTIONS_FILE_UNSET+=PAM OPTIONS_FILE_SET+=SSL OPTIONS_FILE_SET+=TZDATA OPTIONS_FILE_SET+=XML slippy$ pkg info -I krb5 krb5-1.16 MIT implementation of RFC 4120 network authentication service slippy$ I suspect that this may be an environmental issue.
No, this is not an environmental issue. When setting options GSSAPI, the postgresql Makefile explicitely sets 'LDFLAGS+=-lgssapi', and therefore configure will always look for the Heimdal gssapi. If this were not set, then configure would at first look for a -lgssapi_krb5 and then for -lgssapi, and therefore would find a MIT kerberos even with an unmodified base containing the Heimdal gssapi. The issue got more relevance since pgadmin4, since version 5.3, now uses Gssapi credstore extension, and this is currently only available in MIT. (Heimdal has it in head, but not in the current 7.7 release). What you can do, is: compile and link the postgresql with Heimdal gssapi from base, and then force it to runtime-link with the MIT gssapi, by means of the appropriate LD_PRELOAD settings. Since gssapi is pretty standardized, and since the latter is a superset, this actually happens to work. (But I would not want to do this in production; it rather happened to me accidentially.) I would much appreciate to get the radio buttons just like almost everything else in ports has them. I have built a separate instance WITHOUT_KERBEROS to run my pgadmin4, but I definitely do not want to also change my entire build&deploy scheme to also do WITHOUT_KERBEROS.