krb5-1.6.4-beta1 is available
raeburn at MIT.EDU
Fri Apr 4 19:54:41 EDT 2008
On Mar 31, 2008, at 12:15, Damian Hazen wrote:
> Ken Raeburn wrote:
>> Unfortunately, we don't have any functional AIX systems to test
>> with here. (We used to have an AIX 4 system, donated by IBM, but
>> its disk died and we've done nothing about it, much like our
>> scrounged Tru64 5.1 system. No AIX 5 to play with.
> You may not have been expressing that you have time or interest in
> having access to an AIX 5 system, but I've forwarded this message to
> the group at IBM that we do joint development with to see if they
> can help. They've asked if you recall the individual within IBM that
> provided the AIX 4 system.
I wasn't trying to, specifically, no. :) Actually, we're still trying
to figure out how much effort we want to put into some of these
platforms, and we haven't reached any conclusions yet about AIX. I'd
have to dig through some old email archives to dredge up the info;
it's been a few years and I don't recall for sure...
>> So far as I've heard, these platforms aren't the highest priorities
>> to support among our sponsors.) This is, I think, the first
>> "normal UNIX" build system (i.e., not Mac OS X, which is already
>> treated specially in a bunch of ways) where dynamically loaded
>> objects (e.g., preauth or kdb plugins) and shared libraries (e.g.,
>> libkrb5) can be built differently, so it may take a few rounds of
> We submitted http://krbdev.mit.edu/rt/Ticket/Display.html?id=5770 a
> while back, and have been running with it. The db2 kdb plugin works
> but we haven't exercised any others. Should plugin support include
> the ability to rebind symbols? If so, then run time linking needs
> to be specified when building the executables that use the plugins -
> something this patch doesn't provide for. We also didn't fix up
> the link command for gcc compilation, but I can easily resubmit the
> patch with gcc support.
We should probably just pull in your patch... actually, yes, a version
that supports gcc also would be preferable, if you don't mind.
>> I'm unclear on whether the previous change was broken since,
>> incomplete, or just wrong; I'm quite willing to believe we broke
>> something since getting the patch or in applying it.
>> https://krbdev.mit.edu/rt/Ticket/Display.html?id=3176 has the prior
>> discussion that led to these changes in the first place.
> Hmmm... the intent here was to build both run time linking shared
> objects and traditional (for AIX) wrapped shared objects for all
> libraries, and the kerberos build probably broke when static library
> support went a way. Reincorporating this behavior is a bigger job,
> and I wonder if run time linking, for say libkrb5 is necessary.
> BTW, AIX supports dlopen()'ing shared objects in .a's as well.
Well, we know at least some people want to be able to dynamically load
Kerberos and GSSAPI code into applications. (How much anyone cares
about *unloading* afterwards, I'm not certain, but we've tried to keep
that working too.) Whether we really need to deal with building both
shared libraries and dynamically loadable objects for the same library
on systems where they're different, I don't know; I could go back and
read through 3176 again, but without being more familiar with AIX I
don't know that I can really judge. And our current build system kind
of assumes that in any given library directory you might build one or
the other, but not both. :(
More information about the krbdev