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