Coda File System

Re: Coda-client-setup 0.5 released

From: Jan Harkes <>
Date: Mon, 7 Mar 2005 17:56:40 -0500
On Mon, Mar 07, 2005 at 07:34:54AM +0100, Ivan Popov wrote:
> The compilation and changes I applied are documented in
>  /coda/
> and corresponding
>  /coda/*
> (including your contributions, Stephen, thanks - mentioned in .../NOTES)

I browsed through your patchsets.

    Should be fixed, you're not applying those anymore either.
    Already fixed using a bourne shell implementation of which, iterates
    through $PATH, trying to find the executable.

    Just committed a fix for that, configure now searches for res_9_init
    which seems to pull in the libresolv library on Darwin.

    Fixes a problem in the modular clog patch.


    I don't know why configure picks up kerberos4. I could split the
    with-crypto flag into separate -openssl -krb4 and -krb5 flags if you
    want more control over which libraries get linked in.

    I guess this should be an autoconf test, but since we already use
    the platform check for DJGPP, I guess it can't hurt. Applied...

    Looking at the FreeBSD patch, I'm starting to wonder why everyone
    seems to be needing this. Is there some other header that might
    the necessary ioctl bits?

    Seems like the right thing, the finer details of how to mount /coda
    is one of those things we can't reliably test with an autoconf macro.

    Not necessary. It seems like 'patch.fix.killing.realms' actually
    was making some change which resulted in the cunlog breakage. As
    you're not applying that patch, this one isn't necessary.

    Maybe we really just need to include the correct time.h or
    sys/time.h header?
    Seems to be against modular clog. configure should pull -lresolv
    into $(LIBS) if the platform happens to need it.

    Not sure if I want to merge it just yet, although it looks like it
    is getting some decent testing already.

btw. the openssl dependency isn't necessary, we only link against it for
the md5 and sha1 checksum functions. If the library isn't found we use
a generic C implementation (I believe the original reference
implementation). openssl could be providing some optimized assembly
version for your platform, but I don't think we use these functions
often enough that that will result in a measurable difference.

Received on 2005-03-07 17:58:21