possibly acceptable workaround for rlm_perl/dlopen problem on Debian

[Alan DeKok]

Enrik Berkhan wrote:
>>   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).

  That's what I meant, in other words...

> 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.

  That's nice, but why then does "perl ... ldopts" print "-lperl"?

  It's broken.

  if the shared libraries had proper inter-library dependencies, then
different libfoo.so.X could be installed without a problem.  But because
there's no inter-library dependencies, those dependencies have to be
managed with packages.  WTF?

> 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 :)

  No.  If Data/Dumper.so depends on libperl.so.5.8, it should fscking
say so.  Relying on the application to manage Perl's library
dependencies is retarded.

> 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.

  Or "your system is broken.  File a complaint at http://bugs.../12345"

  Alan DeKok.