kerberos5: Undefined symbols: __et_list

[ryandesign (Ryan Carsten Schmidt)]

I cannot build kerberos5 on Lion with Xcode 4.3.3:

:info:build Undefined symbols for architecture x86_64:
:info:build   "__et_list", referenced from:
:info:build       _initialize_prof_error_table in prof_err.so
:info:build ld: symbol(s) not found for architecture x86_64
:info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)

$ clang -v
Apple clang version 3.1 (tags/Apple/clang-318.0.61) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix

Using llvm-gcc-4.2 instead succeeds.

[neverpanic (Clemens Lang)]

Can you attach the log for llvm-gcc-4.2? __et_list should be in libcomerr, can you verify that using nm $prefix/lib/libcom_err.dylib | grep et_list? It seems to me the linker invocation is missing a -L$prefix/lib and thus probably doesn't find libcom_err.dylib.

[aphor (Jeremy McMillan)]

I can confirm on my Lion system it is trying to build

cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_net_kerberos5/kerberos5/work/krb5-krb5-da9dc1b/src" && /usr/bin/make -j16 -w all

with no -L to help it find any libcom_err.dylib, especially the /opt/local/lib/libcom_err.dylib which I confirmed implements the missing et_list symbol.

I took a peek at the Makefile, and found it sets an interesting ld option: -search_paths_first. So then I looked it up and "man ld" yields this possibly interesting news:

    -search_paths_first
                 This is now the default (in Xcode4 tools).  When processing
                 -lx the linker now searches each directory in its library
                 search paths for `libx.dylib' then `libx.a' before the moving
                 on to the next path in the library search path.

     -search_dylibs_first
                 Changes the searching behavior for libraries.  The default is
                 that when processing -lx the linker searches each directory
                 in its library search paths for `libx.dylib' then `libx.a'.
                 This option changes the behavior to first search for a file
                 of the form `libx.dylib' in each directory in the library
                 search path, then a file of the form `libx.a' is searched for
                 in the library search paths.  This option restores the search
                 behavior of the linker prior to Xcode4.

Makefile contains: LDFLAGS = -arch x86_64 -arch i386 -Wl,-search_paths_first Maybe I misunderstand, but the new Xcode's default linker option (set explicitly in the Macport, presumably to make the old Xcode llvm ld behave as the new one) seems to be set for searching default library paths. Trouble: $prefix is not defined until later in the Makefile, so I'm not sure how $prefix/lib should be added to the -L linker options.

[neverpanic (Clemens Lang)]

Can you check whether this is fixed with r105939?

[neverpanic (Clemens Lang)]

Assuming fixed due to lack of repsonse.