Error while compiling krb 1.5

[Henry B. Hotz]

Are we barking up the wrong tree?  Let me propose the following:

As someone noted, you can use libdl to access symbols in a statically  
linked program.  I think what we really want/need is code (and  
configure logic) that will use libdl that way and Do The Right Thing  
(TM) based on whether libdl is functional on the target platform,  
independent of static/dynamic linking.  (Does MIT even support  
platforms without a functional libdl?)

If you need a static build *with* a plug-in, then it's not  
prohibited.  You get extra pain because it's (partly) outside MIT's  
responsibility:  you get to do the linking yourself.

I think MIT should provide a functional static build with no plug- 
in's (or with the minimally-necessary plug-in's).  If it's initially  
buggy in the presence of extra statically linked plug-in's I think we  
can live with that.  It's the nature of Open Source software that  
"strange" configurations are buggy, at least to start with, and I  
don't see this as a "core" configuration.

If the Sun-donated mech glue (thanks, Sun) won't support the above,  
then maybe the static build only has the gss mechanism.

Does this help the discussion any?

On Jul 8, 2006, at 9:05 AM, krbdev-request at mit.edu wrote:

> Date: Sat, 08 Jul 2006 02:04:58 -0400
> From: Marcus Watts <mdw at umich.edu>
> Subject: Re: Error while compiling krb 1.5
> To: krbdev at mit.edu
> Message-ID: <200607080604.CAA17566 at quince.ifs.umich.edu>
>
> Sam Hartman <hartmans at mit.edu> writes:
> ...
>> Well, I think I've made our position reasonably clear: we're not
>> spending time on any of this but we're willing to evaluate designs  
>> and
>> patches from others.
>>
>> Let me know if you would like me to better define the requirements
>> I've sent out.
>
> I agree you sent out quite a bit on requirements already.
>
> That brings us right back around to "agreeing on semantics".  The
> reason I proposed specific cases was to elicit comment and progress
> here.  The different cases I proposed would all "solve" the static
> library problem, with different semantics, and build consequences.
> Some of those might affect MIT future plans, or others.  So far, / 
> 3/ is
> easy to hate.  Your requirements express lack of faith in /2/, but  
> that
> is what pam does today.
>
> So let me ask you this:
> /1/ you say GSS mechs might be plugins.  Do you have plans or
> intentions for other plugins.  Are these only on the kdc machine, or
> the gss libraries, or do you expect to be making significant  
> changes to
> other parts of the library environment a vanilla k5 client
> application might see?
>
> /2/ what systems do you currently support today -- ie, when you
> say "portable" - I'll bet you don't mean ebcdic or 16-bit, but do you
> include aix 4.3?  sgi irix?  Do you expect everything to run  
> everywhere
> (ie, kdc on ms windows, or both static and shared libraries on aix 3.2
> say?)  Also, surely you don't expect your contributors to have access
> to exactly the same set of architectures?
>
> /3/ it seems to me you've already got the complexity when you expect
> initializer routines to work in plugins.  c++ constructors aren't
> really part of the C language, so you got mess there.  Shared objects
> are inherently hairy - even libtool won't fix that.  Somewhere here
> you're going to end up trying to draw a line in the sand.  So perhaps
> more importantly, how do you expect people who want to do more to
> cope?
>
> also for others,
> /4/ Would other people find a libkrb5_pic.a of interest or useful?
> Would --disable-servers be of use to them?  Do people actually expect
> to link krb5kdc statically, and if so, what do they actually expect  
> this
> to mean for plugins?
>
> 					-Marcus

------------------------------------------------------------------------ 
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu