This one time, at band camp, Enrik Berkhan said:
Hi,
I've investigated this bug and found the reason why perl .so's won't load via shared rlm_perl on Debian.
rlm_perl will be loaded by freeradius via lt_dlopenext() which proxies to dlopen(). rlm_perl depends on libperl. Thus, libperl will be loaded indirectly by dlopen() using the same flags specified to dlopen() by lt_dlopenext(). On debian, this means, libperl will be loaded _without_ RTDL_GLOBAL being set.
On the other hand, when the embedded script tries to load a shared perl extension like Data::Dumper, perl's extension mechanisms will load Dumper.so. But Dumper.so does _not_ depend on libperl, so the dlopen() used to load Dumper.so will
1. not search for symbols in libperl explicitly and
2. not see the symbols from libperl loaded earlier indirectly by lt_dlopenext(), because RTLD_GLOBAL is disabled on debian for valid reasons (see bug #195821).
I'm not sure, but I think the correct solution would be to have a shared library dependency from all perl extension modules like Dumper.so on libperl.
BTW, a workaround is to start radiusd with LD_PRELOAD=...libperl... pointing to the correct libperl. Of course, this is not feasible for packaging ...
Thank you for this comprehensive review and investigation of the problem. This is roughly what we arrived at as well. Sadly, the best place for this to be fixed is in ltdl, and a request has been filed with them to add a function to call dlopen with RTDL_GLOBAL. There is not much we can do now except wait (or use the bundled copy of libltdl in the freeradius source, which feels wrong to me as a distribution choice). Thanks, and take care, -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------