This looks like the same issue several people have hit before, in bug 156787, bug 177707, bug 197482 System is 8.4-p24 AMD64. pkg install apache24 and ap24-mod_auth_kerb2, get this error: # service apache24 onestart Performing sanity check on apache24 configuration: httpd: Syntax error on line 175 of /usr/local/etc/apache24/httpd.conf: Cannot load libexec/apache24/mod_auth_kerb.so into server: /usr/local/libexec/apache24/mod_auth_kerb.so: Undefined symbol "gsskrb5_register_acceptor_identity" Starting apache24. httpd: Syntax error on line 175 of /usr/local/etc/apache24/httpd.conf: Cannot load libexec/apache24/mod_auth_kerb.so into server: /usr/local/libexec/apache24/mod_auth_kerb.so: Undefined symbol "gsskrb5_register_acceptor_identity" /usr/local/etc/rc.d/apache24: WARNING: failed to start apache24 Quick mailing list search suggests its due to incorrect linker flags when building the apache module. I can work around it by building the port and linking against a different kerberos, but this really only makes sense to link against base, if neither of those other kerberos bits is a dependency.
Bumping priority a bit -- this seems to be a recurring issue. Tried building from ports (as opposed to the preinstalled package) and it fails at the same spot. I've seen commits against this port that claim that adding -lgssapi_krb5 to ldflags is the fix, but I don't see that being called in my lib output -- when I do that manually I get a different error, but I'm not sure I'm doing it the "right" way. This is trivial to test on an 8.4 machine, just install both packages. If you need more output please let me know. -Dan
Building against the "krb5" package yields: [activating module `auth_kerb' in /usr/local/etc/apache24/httpd.conf] # service apache24 onestart Performing sanity check on apache24 configuration: httpd: Syntax error on line 175 of /usr/local/etc/apache24/httpd.conf: Cannot load libexec/apache24/mod_auth_kerb.so into server: /usr/local/libexec/apache24/mod_auth_kerb.so: Undefined symbol "krb5_rc_dfl_init" Starting apache24. httpd: Syntax error on line 175 of /usr/local/etc/apache24/httpd.conf: Cannot load libexec/apache24/mod_auth_kerb.so into server: /usr/local/libexec/apache24/mod_auth_kerb.so: Undefined symbol "krb5_rc_dfl_init" /usr/local/etc/rc.d/apache24: WARNING: failed to start apache24 Heimdal took forever to build but yielded this error: Installing ap24-mod_auth_kerb2-5.4_7... [activating module `auth_kerb' in /usr/local/etc/apache24/httpd.conf] # service apache24 onestart Performing sanity check on apache24 configuration: httpd: Syntax error on line 175 of /usr/local/etc/apache24/httpd.conf: Cannot load libexec/apache24/mod_auth_kerb.so into server: /usr/local/libexec/apache24/mod_auth _kerb.so: Undefined symbol "__gss_c_nt_hostbased_service_oid_desc" Starting apache24. httpd: Syntax error on line 175 of /usr/local/etc/apache24/httpd.conf: Cannot load libexec/apache24/mod_auth_kerb.so into server: /usr/local/libexec/apache24/mod_auth _kerb.so: Undefined symbol "__gss_c_nt_hostbased_service_oid_desc" /usr/local/etc/rc.d/apache24: WARNING: failed to start apache24 # pkg delete heimdal Let me know if you need any other info. For what it's worth, this system was FreeBSD 8.1, upgraded to 8.4, using freebsd-update.
thanks for the title tweak. One shouldn't submit bugs on low-sleep. :) -Dan
Okay, so I've found the issue here, by looking back at old mailing list posts. FreeBSD uses a somewhat modified heimdal kerberos in base. Kerberos comes with a tool that tells compilers how to build kerberos-using libraries and programs. When FreeBSD modifies kerberos, they don't update the tool correctly. Ergo, the very simple one-line patch to this utility mentioned here in 2011, fixes it: https://lists.freebsd.org/pipermail/freebsd-apache/2011-April/002207.html So, on the solution -- It doesn't look like this was fixed in 8.x, at least according to the dates on: http://svnweb.freebsd.org/base/stable/8/kerberos5/ Another user was having problems on 9.x, as well, in bug 197482. I guess the import of a newer kerberos for 10.x caused this to be corrected. Further, on my 8.x machine, the official package for this port is also broken in the exact same way -- this doesn't get caught because it's a runtime failure, not a build-time one. Whomever maintains this port should probably add ifdefines or whichever to get around this, but the port *really should* be able to trust krb5-config. The "workaround" is to manually patch krb5-config, build this pkg from ports, and install it, then pkg lock it. Then change krb5-config back. -Dan Mahoney
No longer an issue, resolving.