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.