Bug#416266: freeradius: rlm_perl has symbol lookup errors when loading additional perl modules

[Alan DeKok]

Enrik Berkhan wrote:
> Alan DeKok schrieb:
>>   b) The output of perl -MExtUtils::Embed -e ldopts / ccopts
>>      should stop telling applications that linking will work.
>>      It won't.  It's lying to you.  If the libperl-dev package
>>      isn't installed, "perl ... ldopts" should return an error.
> 
> That's completely right. Maybe you should reply on Debian Bug #186778
> (http://bugs.debian.org/186778). But the package maintainers don't seem
> to be interested in it :(

  An alternative explanation makes it clearer that this is strictly a
debian issue.

  RTDL_GLOBAL is disabled on Debian for a number of good reasons.  This
means that an application can link to libfoo.so, and it's symbols aren't
exported to other libraries.  This limitation prevents a number of bugs
from occurring.

  However, there are cases where you *want* other libraries to use those
symbols, as here.  Since the system has shared libraries enabled, this
means that an application cannot know at compile time which libraries it
needs to link to.  In this case, Perl supports dynamically loading of
Perl modules... which includes shared libraries.

  If an application links to Perl, *and* the perl scripts load modules
dynamically, *then* it will load modules at run-time.  Which modules are
to be used is not known at compile time.  So the application cannot link
to every shared library it needs, because it doesn't know which library
it needs.

  Since RTLD_GLOBAL is turned off, the application knows it needs a
library, links to it, but those symbols aren't exported to other shared
libraries using that one.

  Since shared library dependencies are broken (Data/Dumper.so doesn't
depend on libperl.so), the correct libraries aren't loaded, and the
application breaks.

  Since no static library of libperl.a is supplied by the system, the
application can't link to it.  If it did exist, it's symbols could be
exported, because it isn't a shared library.

  a) enable RTLD_GLOBAL

  b) supply libperl.a along with the Perl headers, so
     "perl -MExtUtils::Embed -e ldopts" stops lying to the application
     developer that linking works

  c) fix the inter-library dependencies so that loading Data/Dumper.so
     (etc) will cause libperl.so to be loaded, too.

  I understand (a) is undesired.

  It turns out that linking to libperl.a is almost unworkable, too.
FreeRADIUS uses libtool to do cross-platform linking.  This means it's
very difficult to control which "libperl" is used for linking.

  The appropriate solution is (c).  If there's no RTDL_GLOBAL, then the
ONLY way applications can link to shared libraries at run time is if the
shared library dependencies are correct.

  If this isn't done, then Debian systems are the *only* systems where
FreeRADIUS can't use libperl.  All other systems have working libraries.


  On top of everything else, 'perl -MExtUtils::Embed -e ldopts' outputs
-lperl, but there is NO "libperl.so" on the system.  Instead, there's
only "libperl.so.5.8".  So using Perl to link to the Perl libraries
doesn't work.

  Alan DeKok.