Gssapi Questions

[Marcus Watts]

> Date:    Wed, 24 Aug 2011 21:39:26 PDT
> To:      "'Marcus Watts'" <mdw at umich.edu>
> cc:      <kerberos at mit.edu>
> From:    "Allen McWongahey" <allenmcw at comcast.net>
> Subject: RE: Gssapi Questions
> 
> Hi Marcus,
> 
>  
> 
> Sorry, I should have specified more how I fixed the compile flags which
> caused gcc to fail. I did indeed go through the Config.cache and figured out
> the right variables to set and "configure" no longer set those flags in the
> first place. E.g., I had done exactly what you responded with.
> 
>  
> 
> The problem about the error with <sys/stat.h> is a complete mystery though.
> This occurs when compiling Kerberos (NOT OpenSSH) and note the error below
> which is in a Kerberos source file:
> 
>  
> 
> prof_file.c: In function `profile_update_file_data_locked':
> 
> prof_file.c:330: structure has no member named `st_mtim'
> 
> make[3]: *** [prof_file.so] Error 1
> 
>  
> 
> Now as I understand it "--oldincludedir" should specify the location of the
> system header files, correct? I set this variable to "/usr/include" and
> there IS a "sys/stat.h" header file off of /usr/include. This should be the
> header file that "prof_file.c" is including. Please note that the above
> error says that there is no member named "st_mtim" so it obviously found the
> stat.h header file.
> 
>  
> 
> So I wrote a stand-alone program to include the same header file and that
> member (st_mtim) IS present and my stand-alone program compiles with this
> and works properly. I accessed the struct member in exactly the same way as
> line 330 of "prof_file.c". So I am really baffled how my stand-alone program
> compiles and yet prof_file.c does not.
> 
>  
> 
> I may well still be missing some argument to "configure" which could be
> causing this but I am at a loss to understand how something this simple
> could fail. L
> 
>  
> 
> Thanks much
> 
> Allen

Unless you're very very careful how you constructed /usr/include,
it's almost certainly wrong.

*How* wrong depends -- and since you never said what you're running
on your PPC 8270, I'm going to hate speculating...

Let's assume linux.

"/usr/include/bits" includes a lot (but not all) of the hardware specifics.
bits/endian.h defines the byte order -- the PPC can run in either little-endian
or big-endian as I recall.  linux ppc (and most but not necessarily all ports)
run in big-endian mode.
So if you see:
x86_64 is little-endian.
#define __BYTE_ORDER __LITTLE_ENDIAN
in /usr/include/bits/endian.h - or more particularly, if your kerberos 5
build sees that - you're in trouble.  The crypto will very likely build, and it
might even produce self-consistent results, but it won't talk to anybody
else's crypto implementation.
There will be other less obvious places where there are machine dependencies.
Not all of the machine dependencies will make sense.
Observe this comment in asm-generic/stat.h:
 * Everybody gets this wrong and has to stick with it for all
 * eternity.
Also note the comment about padding just after that.

When you build eglibc - there's a step where you tell it where your kernel
headers are - and the ?prefix?/include that it builds in response includes
those kernel headers plus perhaps additional changes for your target environment.
You need those headers, not the headers for your host environment.
If you're cross-compiling, those headers do not go in /usr/include,
and if you put them there, you will break host compiles, which will
cause its own set of peculiar weirdnesses.

It *is* possible to make /usr/include work across multiple architectures.
You'll have to put ifdef CPU defines by hand in various relevant places
to make it work.

st_mtim is sprawled across asm-X/stat.h, asm/stat.h, and bits/stat.h.
Exactly what is used depends on (a) what architecture you're building for,
and (b) a whole bunch of preprocessor defines that can hook off the language
flavor you specify as well.  Depending on those, you might have st_mtime,
st_mtim, st_mtimensec, and it looks like the kernel itself might be
using something slightly different than what most userland code sees.

If you dig through config.log,
configure will note lots of information on what failed.  For failing
C programs (which the preprocessor tests should count as), those
tests include,
	compiler command line
	test program
which you can dig out of the log and run yourself by hand.
If your configure tests are failing with a false success - you
could modify configure and inject a syntax error.
There will almost certainly be a long string of command line
options.  If you vary those by hand, you'll probably get different
behavior.

If on the compile line, you replace "-c" with -dD -E", you can get the
compiler to dump the results of preprocessing to its output.
This includes notations on all the files it read, and all the manifests
it defined as a result of processing.  Again, you'll see differences
as you manipulate command line options, especially -D -std -ansi.

				-Marcus Watts