possibly acceptable workaround for rlm_perl/dlopen problem on Debian
Hi, after thinking over the libperl.so/dlopen problem with rlm_perl on Debian, I have found the following workaround: Just dlopen(libperl.so, RTLD_LAZY|RTLD_GLOBAL) from rlm_perl again. This will have no effect but making the symbols globally visible since the library has been opened already during the load of rlm_perl. Advantages: - no change on other packages needed at the moment - change stays local to rlm_perl - no portability loss as rlm_perl already uses dlfcn.h / dlclose() I have attached a proof-of-concept patch that is missing at least autotools integration and hardcodes the library name. What do you think about this compromise? Enrik
Enrik Berkhan wrote:
after thinking over the libperl.so/dlopen problem with rlm_perl on Debian, I have found the following workaround:
Just dlopen(libperl.so, RTLD_LAZY|RTLD_GLOBAL) from rlm_perl again. This will have no effect but making the symbols globally visible since the library has been opened already during the load of rlm_perl.
Except you can't dlopen libperl.so, because it doesn't exist on the system. Instead, you've got to dlopen libperl.so.5.8. No. That's broken.
What do you think about this compromise?
It's horrible. I'm going to update the "configure" script so that it tries to compile using the "perl ... ldopts" flags. If that fails, it will complain loudly that your system is broken, and you should file a bug, or add to a existing bug report. Alan DeKok.
Alan DeKok schrieb:
Except you can't dlopen libperl.so, because it doesn't exist on the system. Instead, you've got to dlopen libperl.so.5.8.
No. That's broken.
You would never dlopen libperl.so. If you dlopen another package's shared library, you should always use versioned ones. Otherwise, you'll be trapped by every ABI change. The exact version of libperl.so.x.y that has to be used should be determined by autotools (may be with help by ExtMod:: stuff).
It's horrible.
It's a workaround. Thus, it must be horrible. Otherwise, it would be a solution. Additionally, I didn't mean to integrate this in FreeRADIUS directly but to be considered by the Debian FreeRADIUS maintainers. Enrik
Enrik Berkhan wrote:
You would never dlopen libperl.so. If you dlopen another package's shared library, you should always use versioned ones. Otherwise, you'll be trapped by every ABI change.
Then "perl ... ldopts" should print out the proper Perl library version number. It doesn't. It's broken.
The exact version of libperl.so.x.y that has to be used should be determined by autotools (may be with help by ExtMod:: stuff).
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.
Additionally, I didn't mean to integrate this in FreeRADIUS directly but to be considered by the Debian FreeRADIUS maintainers.
I've updated the configure scripts to NOT build rlm_perl if the module can't link. Alan DeKok.
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
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.
Alan DeKok wrote:
Enrik Berkhan wrote: 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?
I do agree completely. inter-library dependencies would be the Right Thing[pm]. But I suspect it won't be easy to convince the Debian perl maintainers to change their core package ... I might be wrong though. Who wants to file the bug? On the other hand, I would like to have an acceptable workaround to promote FreeRADIUS with working rlm_perl for Debian.
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 :)
Hmm ...
$ perl -V:libperl libperl='libperl.so.5.8.4';
That could be a starting point ... Enrik
Alan DeKok wrote:
I've updated the configure scripts to NOT build rlm_perl if the module can't link.
I think you regenerated configure from configure.in revision 1.3 before checking in, but configure.in is at revision 1.4 in HEAD. Enrik
Enrik Berkhan wrote:
Alan DeKok wrote:
I've updated the configure scripts to NOT build rlm_perl if the module can't link.
I think you regenerated configure from configure.in revision 1.3 before checking in, but configure.in is at revision 1.4 in HEAD.
The new code is in the configure script. I just did: edit configure.in re-configure commit configure* rather than edit configure.in commit re-configure commit configure Alan DeKok.
Alan DeKok schrieb:
The new code is in the configure script. I just did:
edit configure.in re-configure commit configure*
rather than
edit configure.in commit re-configure commit configure
Ah, ok, mea culpa. I was mislead because the new code does not output the usual "checking blabla" message. Enrik
participants (2)
-
Alan DeKok -
Enrik Berkhan