possibly acceptable workaround for rlm_perl/dlopen problem on Debian

[Enrik Berkhan]

Alan DeKok wrote:
>   That's not how shared libraries should work.  A system should have:
> 
> libfoo.so.x.y
> libfoo.so.x -> libfoo.so.x.y
> libfoo.so -> libfoo.so.x
> 
>   When you say "-lfoo", the linker should pick "libfoo.so.x.y", OR
> "libfoo.so.x".  Picking "libfoo.so" is broken.

The linker should always pick libfoo.so, resolving it to the "current"
libfoo.so.x(.y) at link (i.e. build) time and leave a reference/depency
for the dynamic/runtime linker pointing directly at libfoo.so.x(.y).
libfoo.so.x(.y) might in turn point to an ABI compatible
libfoo.so.x.y.z. Of course this differs between operation systems and
architectures, that's what libtool is all about.

To allow for different libfoo.so.version be installed at the same time
on the same system to fulfill dependencies for different other packages
is the reason why distributions like Debian maintain libfoo-packages
without libfoo.so and libfoo-dev-packages containing one unique
libfoo.so pointing to one unique libfoo.so.x(.y). This is plain standard
distribution behaviour, IMHO.

This is the behaviour that would have to be kind of re-implemented by
the workaround: Decide at build time using the generic current libfoo.so
what concrete versioned library to dlopen at run time. Should be
feasible by using some kind of AC_TRY_LINK and ldd or so. But in
portable way, argh :)

>   I've updated the configure scripts to NOT build rlm_perl if the module
> can't link.

That's good. May be the failure message could give a hint like 'may be
you have to install a package like libperl-dev to build rlm_perl'. I
think I've seen stuff like that in other places.

Enrik