(Illustration by Gaich Muramatsu)
On Mon, Mar 07, 2005 at 07:34:54AM +0100, Ivan Popov wrote: > The compilation and changes I applied are documented in > /coda/konvalo.org/sw/pm/1/TOP/c/coda/V/cvs20050303/L/2/NOTES > and corresponding > /coda/konvalo.org/sw/pm/1/TOP/c/coda/V/cvs20050303/L/2/BUILD/patch.* > (including your contributions, Stephen, thanks - mentioned in .../NOTES) I browsed through your patchsets. patch.fix.killing.realms patch.no-daemonize Should be fixed, you're not applying those anymore either. patch.no-docbook2man Already fixed using a bourne shell implementation of which, iterates through $PATH, trying to find the executable. patch.-lresolv Just committed a fix for that, configure now searches for res_9_init which seems to pull in the libresolv library on Darwin. patch.uint16 Fixes a problem in the modular clog patch. patch.vldb.h.uint Applied. patch.nokrb4 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. patch.pioctl.h 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? patch.worker.h 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. Applied. patch.cunlog-protection-hack 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. patch.ctime Maybe we really just need to include the correct time.h or sys/time.h header? patch.no-lresolv Seems to be against modular clog. configure should pull -lresolv into $(LIBS) if the platform happens to need it. patch.modular-clog 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. JanReceived on 2005-03-07 17:58:21