This seemed to build okay on fedora core 1 32-bit intel. I haven't tested it yet.
Except afs2k5db.c In file included from afs2k5db.c:35: /root/krb5-1.3.3/src/include/k5-int.h:1816: error: syntax error before "krb5_donot_replay" If you edit k5-int.h:1816 and just remove the ,krb5_donot_replay * it seems to build although it may have an adverse effect. =) There were various warning about incompatible pointer types and redefinitions throughout the build which always make me leary. But thanks! that is the first time I tried to build that package and it didn't choke in a 100 different places. -------------------------------------- Sean O'Malley, Information Technologist Michigan State University ------------------------------------- On Mon, 17 May 2004, Christopher Allen Wing wrote: > Hello, > > I don't know if there is a more current source for the krb5 migration kit > other than: > > http://grand.central.org/dl/contrib/security/particular-krb5/ > > (and if there is a better mailing list for me to send this to, please > let me know) > > > I needed to change a few things in order to build aklog on AMD64 Linux (in > particular, Fedora Core 1). Here are five proposed patches. > > > > autoconf fixes: > > 1. res_search can be a macro (i.e. on recent linux glibc, AMD64). I just > copied the workaround for this out of the openafs source tree: > > http://www-personal.engin.umich.edu/~wingc/aklog/patches/1-res_search.patch > > 2. Some systems use libcom_err as a shared library; in this case, > add_to_error_table() is already provided and we don't need to build it > ourselves: > > http://www-personal.engin.umich.edu/~wingc/aklog/patches/2-com_err.patch > > 3. It looks like MIT krb5-1.3 no longer includes a separate libkrb524, but > instead moved the krb524 functions into libkrb5. Handle this: > > http://www-personal.engin.umich.edu/~wingc/aklog/patches/3-krb524.patch > > > (Those autoconf changes are sufficient to build aklog and asetkey on > Fedora Core 1, AMD64, but I haven't tested them on other systems, so I > wouldn't suggest applying them to the master source yet) > > > 4. Here's a patch to fix some compiler warnings (wrong prototypes, missing > #includes, wrong format strings, etc.): > > http://www-personal.engin.umich.edu/~wingc/aklog/patches/4-warnings.patch > > > > 5. And finally, here's an actual bug. krb5_build_principal() is a varargs > function that expects a list of string pointers, terminated by a final > NULL. The original aklog code used '0' instead, which is passed as an int > and not automatically promoted to a pointer (as would be the case if it > was specified for a fixed argument). On a 64-bit machine, this results in > pushing a 32-bit value onto the stack instead of the expected 64-bit > pointer. So krb5_build_principal() never finds the terminating null and > starts following invalid pointers. > > The fix is to use NULL, not 0. I also changed several instances of > '#define NULL' in some other files to use (void *)0 for correctness. > (although most systems should provide this anyway) > > http://www-personal.engin.umich.edu/~wingc/aklog/patches/5-64bit.patch > > > > These changes are sufficient at least to build the OpenAFS RPMs for AMD64 > systems :) > > > Thanks, > > Chris Wing > [EMAIL PROTECTED] > > _______________________________________________ > OpenAFS-devel mailing list > [EMAIL PROTECTED] > https://lists.openafs.org/mailman/listinfo/openafs-devel > _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
