compiling krb5-1.2.8 for OS X Server 10.2.5

[Alexandra Ellwood]

>Also take a look at the patch to Alpha 2 that I posted to the
>krb5-bugs list:
>
>http://mailman.mit.edu/pipermail/krb5-bugs/2003-April/000803.html

This is not a problem with the MIT Kerberos build system.  The 
problem is that Apple's ld behaves differently than ld on every other 
platform.

On most platforms, ld searches user paths for libfoo.so and then 
libfoo.a.  If it still hasn't found the library, it will search 
system paths (/usr/lib, etc) for libfoo.so and libfoo.a.  In 
pseudocode this would look like:

foreach path in ($(user_paths) $(system_paths)) {
     foreach library in (lib$(libname).so lib$(libname).a) {
         if (exists ($(path)/$(library)) {
            // found it!
         }
     }
}

 From the Mac OS X ld man page, the user path option "-L" is described as:

        -Ldir  Add  dir  to  the  list  of directories in which to
               search for libraries.  Directories  specified  with
               -L are searched before the standard directories.
                               ^^^^^^

Unfortunately, this isn't completely true for Mac OS X.  Mac OS X's 
ld has its loops swapped.  Mac OS X's pseudocode would look more like:

foreach library in (lib$(libname).so lib$(libname).a) {
    foreach path in ($(user_paths) $(system_paths)) {
         if (exists ($(path)/$(library)) {
            // found it!
         }
     }
}

Mac OS X's ld searches for shared libraries in each path and then 
static libraries in each path.  As a result, shared libraries are 
always chosen over static libraries even if there is a static library 
in an earlier search path than the shared library.

This means that if you have a /usr/lib/libkrb5.dylib, you cannot link 
against a libkrb5.a with -lkrb5 even if you specify the path to the 
static library with -L.  You must list it directly on the link line: 
"$(BUILDTOP)/lib/libkrb5.a".

We have filed a bug report with Apple, including a patch to ld -- 
courtesy of the Heimdal developers.  This is a visible change in 
behavior from other Unix development environments, and a problem for 
all Kerberos implementations which build static libraries on Mac OS 
X, not just the krb5-1.3 source tree.

In the meantime, a trivial fix is to move the Kerberos for Macintosh 
dylibs in /usr/lib out of the way and then move them back when you're 
done linking.  This is a lot simpler than making tons of build 
changes to krb5-1.3.  Because the Kerberos dylibs in /usr/lib are 
just symlinks to the Kerberos.framework, KfM will continue to work 
while they have been moved out of the way.

The dylibs you should temporarily move out of the way are:

/usr/lib/libcom_err.dylib
/usr/lib/libdes425.dylib
/usr/lib/libgssapi_krb5.dylib
/usr/lib/libk5crypto.dylib
/usr/lib/libkrb4.dylib
/usr/lib/libkrb5.dylib
/usr/lib/libkrb524.dylib


On a completely unrelated note, you should be aware that if you build 
krb5-1.3 sources directly, they will not share tickets with Kerberos 
for Macintosh.  KfM uses an in-memory credentials cache which the MIT 
Kerberos sources don't know how to talk to.


--lxs
-- 
-----------------------------------------------------------------------------
Alexandra Ellwood                                               <lxs at mit.edu>
MIT Information Systems                               http://mit.edu/lxs/www/
-----------------------------------------------------------------------------
--