kerberos5 @1.13.1 build fail: undefined symbol __et_list

[dazuelos (dan)]

MacOS X	10.7.4
Xcode	4.3.2

Steps to reproduce the problem:

1. port -v clean --all kerberos5
2. port -vs install kerberos5 builds.job=1

→ error on the build step:

Undefined symbols for architecture x86_64:
  "__et_list", referenced from:
      _initialize_prof_error_table in prof_err.so

[dazuelos (dan)]

kerberos5 clean, install

[dazuelos (dan)]

kerberos5 install main.log

[dazuelos (dan)]

The port -v configure kerberos5 shows:

checking which version of com_err to use... system

And:

$ cd /usr/lib
$ nm -a libcomm_err.dylib | grep __et_list
$

When:

$ cd /opt/lib
$ nm -a libcomm_err.dylib | grep __et_list
0000000000002160 S __et_list
$

I think the choice of the system library is wrong.

[neverpanic (Clemens Lang)]

The --with-system-et flag is correct, because without it, kerberos5 will build and install its own private copy of libcomm_err.dylib, which will conflict with other ports. I made the change to move libcom_err into a separate port a few years ago because a different port (I think it was e2fsprogs or something) also installs the library, making the two ports conflict.

However, "system" in this case does not necessarily mean "/usr/lib", it just means "don't build your own copy". This would work fine by default, because we normally pass -L/opt/local/lib (or -L/opt/lib in your case) in LDFLAGS. However, in the case of kerberos5, this will make kerberos link against an older installed version of itself, possibly failing along the way. For this reason, the kerberos5 Portfile explicitly removes this in line 48.

That alone is still not enough for the build to go wrong, because MacPorts also sets the LIBRARY_PATH environment variable to $prefix/lib, which is picked up by modern compilers/linkers before it checks for libraries in /usr/lib. Your toolchain on 10.7, however, seems to be too old for this.

You can apply the following patch to your kerberos5 Portfile to fix the issue locally:

Portfile

@@ -4 +4 @@
 PortSystem                  1.0
 PortGroup                   github 1.0
 PortGroup                   compiler_blacklist_versions 1.0
+PortGroup                   conflicts_build 1.0
 
 github.setup                krb5 krb5 1.13.1-final krb5-
 name                        kerberos5
@@ -43 +44 @@
 
 use_autoreconf              yes
 # kerberos5 fails to build in its own presence, see #23769, #37944 
-# remove ${prefix}/lib from configure.ldflags to allow linking against its own libs first
-# adding ${worksrcpath}/lib is not necessary and pollutes krb5-config --libs and pkg-config files
-configure.ldflags-delete    -L${prefix}/lib
+conflicts_build             $name
 configure.python            ${prefix}/bin/python2.7
 configure.args              --mandir=${prefix}/share/man \
                             --with-system-et \

I'd be willing to take a patch that does what this patch does conditionally on systems that don't support LIBRARY_PATH.

[dazuelos (dan)]

Your patch is OK:

• with port libcomerr available, kerberos5 build succeed,
• without port libcomerr available, libcomerr is built first and kerberos5 build succeed.

Thank you for your correct analysis of this problem :).

On this version of the OS, I don't have any LIBRARY_PATH in my environnment. Nonetheless:

$ port installed | wc -l
     128
$

Hence I think that the couple kerberos5 - libcomerr is a rare (uniq?) case.

[ryandesign (Ryan Carsten Schmidt)]

Replying to dan+macports@…:

On this version of the OS, I don't have any LIBRARY_PATH in my environnment.

Wouldn't matter if you did. MacPorts sanitizes the environment. MacPorts sets its own LIBRARY_PATH environment variable, but your clang is too old to support it. You could also solve the problem by upgrading to Xcode 4.6.3, the last version that works on Lion.

We could fix the port by having it blacklist the old versions of clang that don't understand LIBRARY_PATH.

[dazuelos (dan)]

You are right. The installation of Xcode 4.6.3 (without the command line tools because of expired certificates), plus Command Line Tools (OS X Lion) independantly is fully operationnal.

    $ port clean --all kerberos5
    $ port install kerberos5
    --> OK

I agree with your blacklist proposal targeted on the key point.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

We could fix the port by having it blacklist the old versions of clang that don't understand LIBRARY_PATH.

r136471