libserf builds against base despite settings?

ShelLuser

ShelLuser

Hi gang,

I'm revising my LAN server a bit (odd name, I know ;)) and ran into a problem while building devel/subversion:

Code: 
/usr/local/lib/libserf-1.so: undefined reference to `__gss_c_nt_hostbased_service_oid_desc'
/usr/local/lib/libserf-1.so: undefined reference to `__gss_spnego_mechanism_oid_desc'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [subversion/tests/cmdline/atomic-ra-revprop-change] Error code 1

make[2]: stopped in /usr/ports/devel/subversion/work/subversion-1.9.7
1 error
It's obvious that libserf-1.so is having an issue here, this library is provided by www/serf. I can back up this conclusion because as soon as I disable the SERF option for Subversion everything builds cleanly.

For my encryption I rely on both security/openssl and security/heimdal, I also set ssl=openssl in /etc/make.conf to reflect on this.

Serf is configured to use security/heimdal and Heimdal is fully up to date. All ports are up to date by the way.

Yet when I check /usr/local/lib/libserf-1.so.1.3.0 using ldd I noticed something very peculiar:

Code: 
/usr/local/lib/libserf-1.so.1.3.0:
        libssl.so.9 => /usr/local/lib/libssl.so.9 (0x28217000)
        libcrypto.so.9 => /usr/local/lib/libcrypto.so.9 (0x28c00000)
        libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x28316000)
        libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x2831f000)
        libheimntlm.so.11 => /usr/lib/libheimntlm.so.11 (0x28387000)
        libhx509.so.11 => /usr/lib/libhx509.so.11 (0x2838e000)
        libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x283ce000)
        libhcrypto.so.4 => /usr/local/lib/heimdal/libhcrypto.so.4 (0x28f2b000)
So instead of using /usr/local/lib/heimdal/libgssapi.so.3.0.0 and libkrb5.so.26.0.0 it reverted back to the libraries of the base system. So yeah, obviously something isn't right here.

My question: which package would be at fault here?

See, at first I am tempted to blame www/serf. After all: I clearly enable Heimdal support and then it doesn't build against Heimdal. But it's also fair to say that several libraries (databases/db5 for example) set up symlinks in /usr/local/lib which I could imagine makes it easier for other packages to detect and use those libraries. And security/heimdal doesn't do this.

For now I'm going to disable Kerberos support entirely because I need https support in Subversion, but I think this problem also needs to be solved.
 
Make sure you enable HEIMDAL and not HEIMDAL_BASE (for www/serf):
Code: 
41 	.if ${PORT_OPTIONS:MHEIMDAL_BASE}
42 	SCONS_ARGS+=    GSSAPI="/usr"
43 	.endif
44 	.if ${PORT_OPTIONS:MMIT} || ${PORT_OPTIONS:MHEIMDAL}
45 	SCONS_ARGS+=    GSSAPI="${LOCALBASE}"
46 	.endif
 
Thanks for the feedback, but I got that covered:

Code: 
peter@macron:/usr/ports/www/serf# make showconfig
===> The following configuration options are available for serf-1.3.9_1:
     DOCS=on: Build and/or install documentation
====> Kerberos support: you can only select none or one of them
     MIT=off: MIT Kerberos (security/krb5)
     HEIMDAL=on: Heimdal Kerberos (security/heimdal)
     HEIMDAL_BASE=off: Heimdal Kerberos (base)
Going to prepare an e-mail to the port maintainer later on.
 
Yeah, it's possible the configure script from serf itself may be detecting the base Heimdal, regardless of how you configure the port. Have you tried building it against MIT? Just to see if that does pick up the correct port dependency?
 
SirDice said:
Have you tried building it against MIT? Just to see if that does pick up the correct port dependency?
Click to expand...
Good thinking! I haven't yet but I'm going to test that as well before actually sending the e-mail, that can definitely shed a little more light on this.
 
I have the same problem. Building Serf against MIT does solve the problem, but results in conflicts down the road.

Update: Building Serf against Heimdal Base seems to solve my issue.
 
You must log in or register to reply here.
Back
Top