compiling krb5-1.2.8 for OS X Server 10.2.5

[Steven Michaud]

I stand corrected.  Sorry for the confusion.

I paid too much attention to what the gcc man page has to say about
the -L flag ("Add directory dir to the list of directories to be
searched for -l").  I figured that the OS X ld man page's
documentation of the -L flag was simply wrong.  And I'm afraid I
didn't test enough on other platforms :-(

I wrote a little test suite, which I tried out on OS X, Solaris and
Linux.  For those who might be interested, I'll append a copy to this
message.

By the way, my patch doesn't (as far as I know) do any harm.  And I
still think it's the most elegant solution to the problem with ld on
OS X ... especially if Apple refuses to fix the bug.  (The changes I
made, though global, aren't actually very large -- I just used the
DEPLIB variables that have long existed in the MIT Kerberos
makefiles.)

Side note:  I've never had any trouble compiling Heimdal on OS X (which
I've been doing since 10.1), because Heimdal never uses the -l flag to
link against its own libraries.  But I _have_ had trouble compiling
programs (like OpenSSH with Simon Wilkinson's patch) to link against
Heimdal -- problems that I now realize were caused by the problem with
ld on OS X (and by use of the -l flag).

On Fri, 25 Apr 2003, Alexandra Ellwood wrote:

> >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".
>
> ...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linktest.tar.gz
Type: application/octet-stream
Size: 851 bytes
Desc: 
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20030428/aa2d07d4/attachment.obj