rlm_python and dynload problem

[Josip Rodin]

On Thu, Jan 06, 2011 at 03:46:07PM +0100, Aurélien Geron wrote:
> 	libltdl.so.7 => /usr/lib/libltdl.so.7 (0x00007f1018258000)
> => FreeRADIUS seems to rely on libltdl.so.7, as expected.
> 
> #grep -i advise freeradius.ltrace 
> => [no output]  Apparently, the string "advise" is nowhere in ltrace's output.
> 
> #grep lt_dl freeradius.ltrace 
> lt_dlsetsearchpath(0x1bea110, 0x7f27c34d4086, 0, 0xffffffff, 0)                             = 0
> lt_dlopenext(0x7fff94d3d210, 0x7fff94d3d000, 0, 0x7fff94d3d219, 0x2525252525252525 <unfinished ...>
> <... lt_dlopenext resumed> )                                                                = 0x1cffe10
> lt_dlsym(0x1cffe10, 0x7fff94d3d110, 0x2d2d2d2d2d2d2d2d, 0x2d2d2d2d2d6d002d, 0xfefefefefefefeff) = 0x7f27c2771f40
> lt_dlopenext(0x7fff94d3d210, 0x1d004a6, 0, 0xffffffff, 0x2525252525252525 <unfinished ...>

> I hope this answers your questions.

Yep. Somehow, during the build of this package, HAVE_LT_DLADVISE_INIT wasn't
defined after all, so the fr_dlopenext() evaluated into a library call
for simple but insufficient lt_dlopenext(), rather than the less simple
but proper lt_dlopenadvise() and friends.

So apparently I something went wrong while I was building that backport.
(I checked the binary, too.)

I had just written the clean rebuild instructions here, but then
I realized what might be wrong - configure.in says:

AC_CHECK_FUNC(lt_dladvise_init, AC_DEFINE(HAVE_HAVE_LT_DLADVISE_INIT, [], [Do we have the lt_dladvise_init function]))
                                          ~~~~~~~~~~
The underlined part sounds like a copy&waste error that never could have
worked properly in the first place... Alan?

-- 
     2. That which causes joy or happiness.