Re: MIT Kerberos 5 status

[Rich Felker <dalias@aerifal.cx>]

On Sun, Jun 10, 2012 at 02:21:06PM -0700, Isaac Dunham wrote:
> grabbed that version. This does mean that nothing using libverto will
> work with musl (or HP/UX) without some patching...although not many
> packages use libverto, AFAICT.

I've looked at the libverto source and as far as I can tell, the only
thing it uses this hackery for is finding the path to its own .so file
so it can munge that name to make a pathname for its own module files
it wants to load from the same path and with the same version suffix.
This of course is utter nonsense. The correct behavior would be to
either:

1. Don't use any explicit pathname; let the same path search procedure
that found the main libverto.so.0 find the modules. For the version
suffix, it's known when the library is built, so this can simply be
hard-coded in the name passed to dlopen (without a path).

OR

2. Simply hard-code all the paths, and don't necessarily put the
modules in the system lib directory (where they're ugly clutter
anywhere) but instead in a verto-specific directory somewhere.

Of course this whole approach is utter madness. It results in library
code that does not work with static linking. The goal, as far as I can
tell, is to avoid pulling lib glib, libevent, etc. dependencies if the
calling application does not use these libs, which is a nice idea from
a packager's standpoint (*cough* Fedora...), but the same thing could
really be accomplished just by putting all the code in the main
library (static or shared), and making all the references to glib,
libevent, etc. into weak references and not explicitly linking to any
of these libraries (so they're only accessible if the main application
already linked them).

In short, the problem arises because the folks at Redhat are doing
some nasty hackery.

Rich