Upgrading kerberos5 1.7.2_0 to 1.11_0 fails: undefined "_krb5_dbe_lookup_last_admin_unlock" symbol

[outis]

Upgrading kerberos5 package from v1.7.2_0 to 1.11_0 fails during the build stage. The build log (also attached) has the following error:

:info:build  libdb2/recno/rec_close.so libdb2/recno/rec_delete.so libdb2/recno/rec_get.so libdb2/recno/rec_open.so libdb2/recno/rec_put.so libdb2/recno/rec_search.so libdb2/recno/rec_seq.so libdb2/recno/rec_utils.so'
:info:build + /usr/bin/gcc-4.2 -bundle -O2 -arch i386 -arch x86_64 -fno-common -L/opt/local/lib -arch i386 -arch x86_64 -Wl,-search_paths_first -o db2.so kdb_xdr.so adb_openclose.so adb_policy.so kdb_db2.so pol_xdr.so db2_exp.so lockout.so libdb2/hash/hash.so libdb2/hash/hash_bigkey.so libdb2/hash/hash_debug.so libdb2/hash/hash_func.so libdb2/hash/hash_log2.so libdb2/hash/hash_page.so libdb2/hash/hsearch.so libdb2/hash/dbm.so libdb2/btree/bt_close.so libdb2/btree/bt_conv.so libdb2/btree/bt_debug.so libdb2/btree/bt_delete.so libdb2/btree/bt_get.so libdb2/btree/bt_open.so libdb2/btree/bt_overflow.so libdb2/btree/bt_page.so libdb2/btree/bt_put.so libdb2/btree/bt_search.so libdb2/btree/bt_seq.so libdb2/btree/bt_split.so libdb2/btree/bt_utils.so libdb2/db/db.so libdb2/mpool/mpool.so libdb2/recno/rec_close.so libdb2/recno/rec_delete.so libdb2/recno/rec_get.so libdb2/recno/rec_open.so libdb2/recno/rec_put.so libdb2/recno/rec_search.so libdb2/recno/rec_seq.so libdb2/recno/rec_utils.so -L../../../lib -lgssrpc -lgssapi_krb5 -lkrb5 -lcom_err -lk5crypto -lkadm5srv_mit -lkdb5 -lgssrpc -lgssapi_krb5 -lgssrpc -lgssapi_krb5 -lkrb5support -lintl -lresolv -L/opt/local/lib -arch i386 -arch x86_64 -Wl,-search_paths_first -exported_symbols_list darwin.exports -dylib_file /opt/local/lib/libkrb5support.1.1.dylib:../../../lib/libkrb5support.1.1.dylib -dylib_file /opt/local/lib/libkadm5srv.5.1.dylib:../../../lib/libkadm5srv.5.1.dylib -dylib_file /opt/local/lib/libkdb5.4.0.dylib:../../../lib/libkdb5.4.0.dylib
:info:build Undefined symbols for architecture i386:
:info:build   "_krb5_dbe_lookup_last_admin_unlock", referenced from::info:build       _locked_check_p in lockout.so
:info:build       _krb5_db2_lockout_audit in lockout.so
:info:build ld: symbol(s) not found for architecture i386
:info:build collect2: ld returned 1 exit status
:info:build Undefined symbols for architecture x86_64:
:info:build   "_krb5_dbe_lookup_last_admin_unlock", referenced from:
:info:build       _locked_check_p in lockout.so
:info:build       _krb5_db2_lockout_audit in lockout.so
:info:build ld: symbol(s) not found for architecture x86_64

krb5_dbe_lookup_last_admin_unlock is defined in src/lib/kdb/kdb5.c and available in lib/libkdb5.7.0.dylib (checked with nm). It looks like the build is linking against @1.7.2_0's libkdb5.4.0.dylib (note "/opt/local/lib" is the first -L, and the "-dylib_file /opt/local/lib/libkdb5.4.0.dylib:../../../lib/libkdb5.4.0.dylib"), which doesn't define krb5_dbe_lookup_last_admin_unlock.

As a workaround for this issue, the existing ports can be disabled before upgrading:

sudo port deactivate active and rdependentof:kerberos5 kerberos5
sudo port clean kerberos5
sudo port install kerberos5
sudo port activate rdependentof:kerberos5

This looks like a regression to #23769, as the changes introduced in [77769] to the port file have been commented out in [102459].

[outis]

build log

[neverpanic (Clemens Lang)]

Entirely possible. This part in the Portfile is non-standard and wasn't commented as to why it's there. I wonder whether the better solution would be to use a deactivate hack for the previously installed version, though.

[outis]

Replying to cal@…:

[...] I wonder whether the better solution would be to use a deactivate hack for the previously installed version, though.

Is there a standard technique using deactivation? It would have to make sure to deactivate any dependents, then reactivate those (and only the previously active ones) after installation. That aside, I don't see any issues, but I'm not intimately familiar with the vagaries of macport's build framework.

[neverpanic (Clemens Lang)]

Replying to ww.galen@…:

Is there a standard technique using deactivation?

There's a snippet flying around in some Portfiles that can be used for the purpose.

It would have to make sure to deactivate any dependents, then reactivate those (and only the previously active ones) after installation.

Or, it could just ignore any dependents, knowing that a new version will be installed shortly. But I can see how this might cause problems, because we would have to disable any previously installed kerberos before configure and users might not completely run the process all the way to install.

[jmroot (Joshua Root)]

Removing the flags means external libs are found via CPATH and LIBRARY_PATH, which are searched after internal header/lib locations. It was a workaround; the problem is that the flags are being passed in the wrong order in one or more places (internal after external).

[neverpanic (Clemens Lang)]

Fixed in r102976.