Gssapi Questions

[Allen McWongahey]

Hi Marcus,

Thanks very much. I have the Kerberos 5 package now compiling properly for
my cross-target! :)

There is a bit of an issue when trying to recompile OpenSSH with Kerberos 5
support enabled. I get the following:

/opt/timesys/linux/4.0/toolchains/powerpc-linux/bin/powerpc-linux-gcc -o ssh
ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o
sshconnect2.o -L. -Lopenbsd-compat/  -R/home/allenm/kerberos_install/lib
-lssh -lopenbsd-compat -lresolv -lcrypto -lutil -lz -lnsl -lcrypt
-L/home/allenm/kerberos_install/sys/lib -lgssapi_krb5 -lkrb5 -lk5crypto
-lcom_err -lresolv -ldl
/opt/timesys/linux/4.0/toolchains/powerpc-linux/lib/gcc-lib/powerpc-linux/3.
2/../../../../powerpc-linux/bin/ld: warning: libkrb5support.so.0, needed by
/home/allenm/kerberos_install/sys/lib/libgssapi_krb5.so, not found (try
using -rpath or -rpath-link)
/home/allenm/kerberos_install/sys/lib/libkrb5.so: undefined reference to
`krb5int_close_plugin_dirs at krb5support_0_MIT'	
/home/allenm/kerberos_install/sys/lib/libkrb5.so: undefined reference to
`krb5int_gai_strerror at krb5support_0_MIT'
/home/allenm/kerberos_install/sys/lib/libkrb5.so: undefined reference to
`krb5int_clear_error at krb5support_0_MIT'

It seems some support module is being enabled when configuring Kerberos. I
have "--disable-pkinit" set when I run configure, but I've also tried
without this set and the same problem results. I also see a comment in the
Kerberos "configure" file which says:

# Sadly, we seem to have accidentally committed ourselves in 1.4 to
# an ABI that includes the existence of libkrb5support.0 even
# though random apps should never use anything from it.  And on
# the Mac, to which that didn't apply, we can't use major version 0.

Does this have anything to do with the error when I try to build OpenSSH? It
seems to because those undefined references are present in the
"utils/support" Kerberos directory.  Sadly I cannot find anything in
"config.cache" to control this behavior.

Also, there seems to be a problem with OpenSSH following soft links in the
Kerberos 5 install location - also shown in the above output. I have rerun
Kerberos configure with "--disable-rpath" and the soft links are still set
up. I have also tried running the OpenSSH "configure" with "-with-rpath"
argument. 

Thanks much
Allen

-----Original Message-----
From: Marcus Watts [mailto:mdw at umich.edu] 
Sent: Thursday, August 25, 2011 9:19 AM
To: allenmcw at comcast.net
Cc: kerberos at mit.edu
Subject: Re: Gssapi Questions

> 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