Kerberos Cross Compiling

[Ken Raeburn]

On Sep 13, 2004, at 15:31, Sulamita Garcia wrote:
> I'm trying upgrade from krb5-1.3.2 to krb5-1.3.4 in a cross compile 
> enviroment, but it does not work.  I notice that are some changes in 
> aclocal.m4, about cross compiling. I changed it so I can compile and 
> use a MPC 8xx as a kerberos client, but the GSSAPI authentication 
> don't work. In openssh I got a "Generic Unknow RC/IO error", with 
> krlogind I got "Bad sendauth version was sent". Can you help me?

If your tools all work, there's a good chance the problem is in the 
results of the configure tests.

There are probably a few tests that are run that assume that the host 
and target systems (borrowing the GNU terms for cross-compilation 
environments) are the same.  We don't do testing of cross-compilation 
environments, so I can't really tell you which or how many.  I can tell 
you that running "make check" is likely to be very difficult....

If you can identify any configuration tests which are assuming the host 
and target are the same, but can fairly easily be made to not make that 
assumption (e.g., transforming a test from "runs without crashing if 
property X is true" to "won't compile unless property X is true"), we'd 
be happy to take patches.  I might be able to give a limited amount of 
help, though I can't promise anything.  (I've got a couple important 
projects that are not as far along as I'd like.)  Some of the tests may 
be of the form "does X work" or "does X behave this way", which 
requires running a program.  I don't think there's much we can do about 
that.

If some test results need to be forced to have certain results, for 
most of them, you can set the autoconf cache variables in the 
environment or in config.cache before running configure.  You might try 
looking at config.cache after configuring 1.3.2 and 1.3.4 to see where 
they differ.

As for these specific errors, I would probably start by instrumenting 
the code where these error codes are used, to log somewhere the file 
and line number where it's triggered, and any useful information from 
the context (e.g., what sendauth version appears to have been sent).  
If you've got a working debugger, you could also just set breakpoints 
at a bunch of places where the error code could be produced, but 
especially if the compiler is aggressive about optimization, you may 
have trouble properly setting breakpoints based on line numbers.

Ken