Error while compiling krb 1.5

[Marcus Watts]

> From: Sam Hartman <hartmans at MIT.EDU>
> To: Marcus Watts <mdw at umich.edu>
> Subject: Re: Error while compiling krb 1.5
> References: <200607052322.TAA11103 at quince.ifs.umich.edu>
> Date: Thu, 06 Jul 2006 16:56:18 -0400
> 
> >>>>> "Marcus" == Marcus Watts <mdw at umich.edu> writes:
> 
>     Marcus> Various people had written about static build requirements
>     Marcus> and shared libraries vs. objects.
> 
>     Marcus> I think a possible approach here would be to build 2 sets
>     Marcus> of objects in the actual build tree: "static" objects.
>     Marcus> "pic" objects.  the result of the first can be libkrb5.a,
>     Marcus> just like krb5 <1.5.  The result of the second could be
>     Marcus> something like libkrb5_pic.a In theory, the logic for this
>     Marcus> should be similar but simplier than the previous shared
>     Marcus> library logic.
> 
> We could do this, but I don't understand how it solves any of the hard
> problems involved in yesterday discussion.  In particular I don't
> understand how it deals with getting access to plugins.

It sounded to me like you currently have plugins working,
but broke static library support in the process.  I believe
you've mostly been worried about shared library, object, & module
support inside kerberos 5 itself; I believe other people (certainly
myself) are worried about shared library & object & module support
*outside* of kerberos 5 - for instance, building perl 5 modules.
I don't see any of these three things (library, internal modules, or external
modules) as being separate from each other; they all share common
attributes & issues, and in particular, they require some approach for
how to build position independent code & link it at the various required
points.

So far as your internal module case in particular goes, seems
to me you have several possibliities:

	/1/ no "--enable-dynamic".  Obviously the user does not
	want *any* dlopen logic.  Don't build modules at all.
	Link all kerberos servers against static libraries only, don't
	use dlopen, and make sure any required db support has some
	alternative "integrated" code path that doesn't use dlopen.

	/2/ no "--enable-dynamic".  The user does not want .so files.

	But he must still want/need module support else why 1.5?
	So maybe he doesn't really hate dlopen.
	On many (most?) systems a shared object can access and use symbols
	provided by the main load image.  For instance, on Gnu/linux,
	"cc -Wl,-E" on the executable will export symbols in the
	executable for use by shared libraries.  (It may be necessary
	to also use "-u" or some such to ensure the image includes
	symbols it doesn't already use directly.)

	So.  Make sure krb5kdc et all provide any or all required
	symbols.  Modules should link and run using only the symbols
	provided by the kdc (or whatever) image or libc.

	/3/ no "--enable-dynamic".  The user does not want .so files.
	But he must still want/need module support else why 1.5?

	So, build libkrb5_pic.a, and link modules using "-lkrb5_pic".

	You're probably loading in redundant copies of routines
	at this point - but if they can't see each other that
	"should" be mostly harmless, except perhaps to the sanity
	of anybody unlucky enough to be looking for bugs.

I think /2/ is cleanest, but I could see the use for a "--disable-module" 
to force /1/ behavior.  I could also see a "--enable-pic" option to
ask for a libkrb5_pic.a even when not building shared libraries,
but unless doing /3/ that shouldn't affect internal modules.

Another interesting option might be "--disable-server".  Ie, built
client side libraries and tools, but don't bother building krb5kdc
or worry about module support at all.  This *is* entirely a server
side issue, right?

The libpam that's in linux has some crazy option to build "without"
modules.  In that case, they link the "modules" in statically and
do something else to handle initialization and configuration.
I don't think it was particularly pretty, but it might suggest a
way to handle /1/ that isn't completely ugly.

				-Marcus