[2698] in Kerberos_V5_Development
gcc on Rhapsody problem
daemon@ATHENA.MIT.EDU (Alexandra Ellwood)
Fri Nov 7 18:36:39 1997
Date: Fri, 7 Nov 1997 18:36:30 -0500
From: Alexandra Ellwood <aellwood@MIT.EDU>
To: krbdev@MIT.EDU
Hi,
I just built Kerberos 5 on Rhapsody Development Release 1. Namely,
I've kludged the code so it builds. The client binaries all seem to
work, but obviously fully testing it is going to be an ongoing
process.
To those people who are interested in using krb5 on Rhapsody, I am
going to put a snapshot of a recent krb5 build with my changes on the
web so that other people can build krb5 as well. I will also include
instructions for how to avoid a variety of Rhapsody bugs and gotchas
which prevent krb5 from building.
I will send mail here when I have set up the web page so that people
can find it.
Anyway, in the process of getting krb5 to build, I've had to make a
few changes to the sources. This is a list of them so that the krb5
development team has an idea of what needs to be changed. My
understanding is that most of these will need to be changed for one
reason or another anyway.
*** 1 ***
In krb5/src/lib/krb5/asn.1/asn1buf.h there is section of code which
checks for __GNUC__ >= 2 and creates a nasty gcc-specifc macro for
"asn1buf_insert_octet()". The nastiness comes from the use of a
gcc-specific form of the ? and : operators where the parameter
directly following the ? is left blank (and filled in by gcc). While
this speed hack is nice, unfortunately the version check on gcc is not
sufficient to verify that the ? and : operators can be used this way.
Namely, Rhapody's gcc is version 2.7.2.1, however it is built without
some of the gcc-extensions turned on. As a result, this code fails to
compile.
One solution would be to create a configure test for gcc extensions.
However, I spoke with Ted Ts'o about this, and we decided that a
possibly better solution was to attempt to inline this code, rather
than creating a macro for it. Rhapsody gcc does have support for both
inline and __inline__. In addition to fixing the problem, non-gcc
compilers that support inlining could also take advantage of this
optimization.
*** 2 ***
In krb5/src/lib/rpc/, getrpcent.c, netdb.h and rpc_prot.c declare rpc
functions which are already defined in Rhapsody's own system
libraries. This is a problem because the linker refuses to link
anything with duplicate symbols under Rhapsody. I've heard that
duplicate rpc libraries known problem, but I figured I would mention
it.
*** 3 ***
In krb5/src/appl/bsd/v4rcp.c, there is an extern declaration of
sys_errlist which is incompatible with the one in Rhapsody's stdio.h.
It looks like this isn't a new problem since this code is prepended by
a "Kludge!!!" comment and surrounded by a #if which special cases
NetBSD and FreeBSD. I'd just special case Rhapsody in the same,
except that the Rhapsody compiler only defines __MACH__ and NeXT (like
a NeXT or OpenStep machine). I've sent a bug report about this to
Apple, since Rhapsody != NeXT. As a temporary measure until Apple
picks a compiler define for the OS, I may cause the configure scripts
to #define Rhapsody for me when they are run on a Rhaspody system.
Of course this code really should be using strerror().
Cheers,
-- lxs
-----------------------------------------------------------------------------
Alexandra Ellwood <aellwood@mit.edu>
MIT Information Systems http://web.mit.edu/aellwood/www/home.html
"Everybody dies frustrated and sad and that is beautiful."
-----------------------------------------------------------------------------
