krb5-1.6.4-beta1 is available

[Ken Raeburn]

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  
>> debugging.
>
> 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. :(

Ken