[4404] in Kerberos
Re: Porting of V5 to AIX 4.1
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Thu Dec 22 23:04:25 1994
Date: Thu, 22 Dec 1994 22:49:22 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: "Anthony J. Lill" <ajlill@ajlc.waterloo.on.ca>
Cc: alf@minnie.kgn.ibm.com, kerberos@MIT.EDU, krb5-bugs@MIT.EDU
In-Reply-To: [1001]
Date: Wed, 21 Dec 1994 23:09:18 -0500
From: "Anthony J. Lill" <ajlill@ajlc.waterloo.on.ca>
>>>>> "Pat" == Pat Meehan <alf@minnie.nic.kingston.ibm.com> writes:
Pat> Hi all!
Pat> 'Trying' :( to port V5 to AIX 4.1 ... A couple of things...
Pat> When I do a make clean, then try to compile (ie, make ...)
Pat> the make clean rm's some of the source files that came with
Pat> the distribution and so when I issue make it bombs out
Pat> because it can't find certain files (like
Pat> src/util/et/et_c.awk, src/util/et/et_h.awk,
Pat> src/util/ss/ct_c.sed, and src/util/ss/ct_c.awk...)
No, That's a bug. Here's some more you're libel to run into, Plus I
may have forgotten one or two...
Yes, that's one that you run into if the source directory and the build
directory are the same. I generally use separate source and build
trees, so I didn't catch that one before the last release. Sorry about
that!!!
1) The configure script distributed in util/et did not work. Probable
cause is that the command to re-create the Makefile doesn't pass the
--topdir arg to autoconf. Also, for some reason, running autoconf
--topdir=. in src produces a configure script with the head chopped
off, while running autoconf without the argument works.
You're supposed to only need to run the configure script in the top
level, which then automatically recurses down the tree, running
configure in each directory and passing in the appropriate --topdir
argument at the time.
Running configure down in a low-level directory without the correnct
--topdir arguments will cause it to lose. The makefiles that it
generates should be set up so that if the configure file is more recent
that the config.status file, it will automatically re-run the configure
file with the appropriate --topdir arguments. (I'm pretty sure that
made it into pl3.)
2) You should mention somewhere that the autoconf you distribute has
been modified, and the arguments required to generate a working
configuration, this would have saved me a couple of hours trying to
fix 1.
The autoconf that we were using was a pre-2.0 autoconf. Kerberos V5 was
the first product using autoconf that had a very complicated directory
structure, we single-handed held back the autoconf 2.0 release for a
couple of months. :-)
The next release of Kerberos V5 will be using the standard autoconf 2.1.
3) The sed that comes with SVR4 can't handle the ct_c.sed script, you
should probably search for a more appropriate one rather than
hardcoding /bin/sed
Hardcoding /bin/sed is wrong; that will be undone in the next release,
so it just looks for sed where it may be in the search path.
I am curious about SVR4's sed not working on the ct_c.sed script. I had
tested the ct_c.sed script under a large number of platforms, including
System V derivitives, so I had assumed that it would work on most
platforms. If you could send me more details about how ct_c.sed was
failing under SVR4's sed, I'd be grateful.
4) Runing 'make clean' in util/ss removes ct_c.awk and ct_c.sed, and
there is no way to re-create them if srcdir=.
That's a bug. Remove the lines in Makefile.in as a workaround.
6) In include/krb5/configure.in, your check:
AC_CONST
AC_DEFINE(HAS_ANSI_CONST)
which is probably not what you intended.
It is, actually. That's a leftover relic from the autoconf->imake
conversion. The use of defining HAS_ANSI_CONST (an old imake
configuration variable) is to prevent base-defs.h from #defining const
away, since that's done by the AC_CONST test.
Since we've removed all imake support at this point, we should just take
that check out of base-defs.h, and remove the define for HAS_ANSI_CONST
from configure.in.
7) Of course, the eval fails when it shouldn't, so the test is bogus
for me. The stock C compiler rejects the test:
{ /* Sun SC1.0 ANSI compiler rejects this -- but not the above. */
typedef const int *iptr;
iptr p = 0;
++p;
}
Is this the stock C compiler for SVR4? We should find out whether this
is because it doesn't support const correctly, or because this is a bug
in a standard autoconf test. If it's the latter, it should get reported
back to the autoconf folks.
and so sets const to "", however, a number of files
(e.g. lib/krb5/asn.1/asn1_decode.c) include stdio.h, autoconf.h, then
stdlib.h. In both stdio.h and stdlib.h, system is defined as
int system( const char * );
but the second time around, the const is stripped, and the compile
fails.
Can you get me a list of those files? We should really fix the ordering
of the include files to allow for this case.
8) Is it your intention to propagate the DECLARG/OLDDECLARG to all the
kerberos source? If so, I may do some of the work.
The only reason why we're using DECLARG/OLDDECLARG was because of the
decision to make certain types (like the encryption types) be "narrow"
types --- i.e., char or shorts --- and the ANSI allowed behavior that
could allow compilers to do different calling conventions if they know
that a function is declared using narrow types. Hence, only functions
which get passed in parameters that are narrow types currently have
DECLARG/OLDDECLARG applied to them. Elsewhere, the function prototypes
use have prototypes, and we use the standard K&R function headers for
portability without the mess of DECLARG/OLDDECLARG.
It's enough of a mess that I'm considering simply just removing the
use of narrow types from krb5 altogether. It doesn't actually buy you
much (if anything) on most architectures.
9) Anyone working on a way to set NARROW_PROTOTYPES?
NARROW_PROTOTYPES is only supposed to be turned on and off for small
pieces of code, during certain specialized declarations. It's part of a
really ugly hack caused by the fact that we use narrow prototypes, and a
desire for code linked against the kerberos library to work whether or
not the include files containing the function prototypes are linked in
or not.
10) Your test for -lsocket in kdc (probably elsewhere as well) can't
work. On SVR4 -lsocket requires -lnsl, so trying to compile the test
program with -lsocket but without -lnsl will always fail. I switched
the order, and it linked, but only because I'm using shared libs.
Under solaris, it does work, since merely linking in -lsocket without
-lnsl works if you don't actually pull in any of the libsocket.a
routines. This is a tough one; we'll probably have to do a specialized
test to get around this particular bit of SVR4 braindamage....
13) I've had to add networking libs to a number of programs to resolve
htons and friends.
Again, if you can send me the necessary patches, I'd appreciate it....
Thanks a lot for your comments; I really appreciate it!!!!
- Ted
