Opened 6 years ago

Closed 6 years ago

#47583 closed defect (fixed)

kerberos5 @1.13.1 build fail: undefined symbol __et_list

Reported by: dan+macports@… Owned by: ryandesign (Ryan Schmidt)
Priority: Normal Milestone:
Component: ports Version: 2.3.3
Keywords: Cc: neverpanic (Clemens Lang)
Port: kerberos5

Description (last modified by mf2k (Frank Schima))

MacOS X10.7.4
Xcode4.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

Attachments (2)

kerberos5_install_2015-04-28.log (59.1 KB) - added by dan+macports@… 6 years ago.
kerberos5 clean, install
kerberos5_2015-04-28_main.log (103.7 KB) - added by dan+macports@… 6 years ago.
kerberos5 install main.log

Download all attachments as: .zip

Change History (10)

Changed 6 years ago by dan+macports@…

kerberos5 clean, install

Changed 6 years ago by dan+macports@…

kerberos5 install main.log

comment:1 Changed 6 years ago by mf2k (Frank Schima)

Description: modified (diff)

comment:2 Changed 6 years ago by dan+macports@…

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.

comment:3 Changed 6 years ago by neverpanic (Clemens Lang)

Cc: cal@… added

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

     
    44PortSystem                  1.0
    55PortGroup                   github 1.0
    66PortGroup                   compiler_blacklist_versions 1.0
     7PortGroup                   conflicts_build 1.0
    78
    89github.setup                krb5 krb5 1.13.1-final krb5-
    910name                        kerberos5
     
    4344
    4445use_autoreconf              yes
    4546# kerberos5 fails to build in its own presence, see #23769, #37944
    46 # remove ${prefix}/lib from configure.ldflags to allow linking against its own libs first
    47 # adding ${worksrcpath}/lib is not necessary and pollutes krb5-config --libs and pkg-config files
    48 configure.ldflags-delete    -L${prefix}/lib
     47conflicts_build             $name
    4948configure.python            ${prefix}/bin/python2.7
    5049configure.args              --mandir=${prefix}/share/man \
    5150                            --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.

comment:4 Changed 6 years ago by dan+macports@…

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 and libcomerr is a rare (uniq?) case.

Version 0, edited 6 years ago by dan+macports@… (next)

comment:5 in reply to:  4 ; Changed 6 years ago by ryandesign (Ryan 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.

comment:6 Changed 6 years ago by dan+macports@…

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.

comment:7 in reply to:  5 Changed 6 years ago by ryandesign (Ryan Schmidt)

Owner: changed from macports-tickets@… to ryandesign@…
Status: newassigned

comment:8 Changed 6 years ago by ryandesign (Ryan Schmidt)

Resolution: fixed
Status: assignedclosed

Replying to ryandesign@…:

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

r136471

Note: See TracTickets for help on using tickets.