Stephen Gran schrieb:
> 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. The
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 e
Stephen Gran wrote:
> [EMAIL PROTECTED]:~$ dpkg -S libperl.a
> libperl-dev: /usr/lib/libperl.a
$ perl -MExtUtils::Embed -e ldopts
Outputs "-lperl", among other things.
$ perl -MExtUtils::Embed -e ccopts
Prints out where the header files are installed.
But, of course, you can't *use* thos
Enrik Berkhan wrote:
> Maybe it would work to link libperl.a (statically) with rlm_perl to
> workaround the problem? I haven't tried to, yet.
No, this won't help. The symbols from the static libperl.a are present
in rlm_perl and exported, too, but the dlopen(Dumper.so) from DynaLoader
still can't
This one time, at band camp, Alan DeKok said:
> Enrik Berkhan wrote:
> > Maybe it would work to link libperl.a (statically) with rlm_perl to
> > workaround the problem? I haven't tried to, yet.
>
> $ locate libperl.a
> $
>
> Oops.
>
> It would be possible if there *was* a libperl.a. There's
Enrik Berkhan wrote:
> Maybe it would work to link libperl.a (statically) with rlm_perl to
> workaround the problem? I haven't tried to, yet.
$ locate libperl.a
$
Oops.
It would be possible if there *was* a libperl.a. There's no
libperl.a, and the libperl.so dependencies aren't set up corre
Stephen Gran schrieb:
> 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. The
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, libper
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 sp
This one time, at band camp, Stephen Gran said:
>
> It does. Thanks for the test case. This doesn't crash, interestingly:
>
> ==
> use strict;
>
> # This is very important ! Without this script will not get the filled
> # hashesh from main.
> use
tags 416266 +help
thanks
This one time, at band camp, Philipp Kolmann said:
> and a minimal /etc/freeradius/dtcheck.pm:
>
>
> use strict;
>
> # This is very important ! Without this script will not get the filled
> # hashesh from main.
> use vars qw(%RAD_REQUEST %RAD_REPLY %RAD_CHECK);
> use
On Mon, Mar 26, 2007 at 01:56:40PM +0100, Stephen Gran wrote:
> This one time, at band camp, Philipp Kolmann said:
> Huh. Interestingly, etch's perl doesn't seem to be linked against
> libperl. I wonder if that's intended.
Also sid's perl isn't linked to libperl Installed freeradius on my
wo
This one time, at band camp, Philipp Kolmann said:
> moria:~# ldd /usr/bin/perl
> linux-gate.so.1 => (0xe000)
> libdl.so.2 => /lib/tls/libdl.so.2 (0xb7fa6000)
> libm.so.6 => /lib/tls/libm.so.6 (0xb7f81000)
> libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7f6e00
On Mon, Mar 26, 2007 at 01:06:43PM +0100, Stephen Gran wrote:
> This one time, at band camp, Philipp Kolmann said:
> > The Problem seems to be, that /usr/lib/freeradius/rlm_perl.so is linked
> > against /usr/lib/libperl.so.5.8 but perl uses another libperl:
> >
> > perl -V | grep libperl:
> > libp
This one time, at band camp, Philipp Kolmann said:
> The Problem seems to be, that /usr/lib/freeradius/rlm_perl.so is linked
> against /usr/lib/libperl.so.5.8 but perl uses another libperl:
>
> perl -V | grep libperl:
> libperl=libperl.so.5.8.8
>
> When I start freeradius with
> LD_PRELOAD=/usr/l
Package: freeradius
Version: 1.1.3-3
Severity: important
Hi,
I am trying to get freeradius to do some post-auth stuff with an
external perl script I wrote. This script uses LWP::Simple to check if
the User is allowed access or denied.
Also using Data::Dumper raises the same problem:
moria:~# fr
16 matches
Mail list logo
