Opened 12 years ago

Closed 12 years ago

#37944 closed defect (fixed)

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

Reported by: outis Owned by: neverpanic (Clemens Lang)
Priority: Normal Milestone:
Component: ports Version: 2.1.3
Keywords: Cc: jmroot (Joshua Root)
Port: kerberos5

Description

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].

Attachments (1)

main.log (582.5 KB) - added by outis 12 years ago.
build log

Download all attachments as: .zip

Change History (6)

Changed 12 years ago by outis

Attachment: main.log added

build log

comment:1 Changed 12 years ago by neverpanic (Clemens Lang)

Cc: jmr@… added
Owner: changed from macports-tickets@… to cal@…
Status: newassigned

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.

comment:2 in reply to:  1 ; Changed 12 years ago by 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.

comment:3 in reply to:  2 Changed 12 years ago by 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.

Last edited 12 years ago by neverpanic (Clemens Lang) (previous) (diff)

comment:4 Changed 12 years ago by 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).

comment:5 Changed 12 years ago by neverpanic (Clemens Lang)

Resolution: fixed
Status: assignedclosed

Fixed in r102976.

Note: See TracTickets for help on using tickets.