Bug 689045

This Debian bug report contains a discussion of the issue:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416266

FYI I seem to recall there may have been other discussions of the same issue elsewhere, possibly also in the context of Python.

Pasting in an email sent to freeradius-users and freeradius-devel which details the result of my investigations and proposed fixes. That information should be captured here as well.

---------------------------------------------------------------------------

I finally tracked this down and since it affects other people building 
2.1.10 I thought I would pass along the info. Alan please also note 
there is a git formatted patch attached against the v2.1.x git branch 
and I think you also need to run autogen.sh again (see below).

It turns out the fix is to use lt_dladvise* and Alan checked in a fix 
for it on 12/9/2009 in commit 7115d751. However that code does not get 
turned on unless HAVE_LT_DLADVISE_INIT is defined.

Alan checked in a fix on 8/6/2010 in commit 323229c2 which added the 
check for lt_dladvise in configure.in and if found sets 
HAVE_LT_DLADVISE_INIT

opps, but not really the actual symbol which was defined was 
HAVE_HAVE_LT_DLADVISE_INIT (note the extra HAVE_)

This was corrected on 1/7/2011 in commit 03993758.

So if you modify HAVE_HAVE_LT_DLADVISE_INIT to be HAVE_LT_DLADVISE_INIT 
in the 2.1.10 tree, run configure again you should pick up the 
lt_dladvise fixes right? Wrong. Why?

Because src/include/autoconf.h.in which configure rewrites as 
src/include/autoconf.h does not have the HAVE_LT_DLADVISE_INIT symbol in 
it. Why?

Because autoheader was not rerun after modifying configure.in. According 
to the git log it appears as if the headers were last updated on 
1/29/2009, about two years ago.

So the answer is to run autogen.sh right? Sort of, except autogen.sh has 
a bug in it which causes it to exit prematurely before it's performed 
90% of its work (it misses updating *all* the modules although it does 
update src/include/autoconf.h.in). The fix for this is in the attached 
0001-Fix-autogen.sh-the-script-is-invoked-with-e-which-ca.patch.

So what do you need to do if you want to enable lt_dladvise in 2.1.10?

1) change HAVE_HAVE_LT_DLADVISE_INIT to HAVE_LT_DLADVISE_INIT

2) patch autogen.sh so it doesn't exit prematurely (not strictly 
necessary for lt_dladvise, but a good idea, who knows what else was 
getting missed because of it)

3) run autogen.sh

4) do the configure, make, & install dance

Note, steps 1&2 are implemented in attached freeradius-lt-dladvise.patch

Alan:

I think you need to apply 
0001-Fix-autogen.sh-the-script-is-invoked-with-e-which-ca.patch, then 
run autogen.sh, and then do a git commit.

HTH,

John

Created attachment 487398 [details]
git patch for autogen.sh

Created attachment 487399 [details]
patch used in spec file

Note, this comment will be added to the spec file

# WARNING, when the lt-dladvise patch is removed the autogen.sh in the
# prep section should be removed as well, it's only necessary because
# upstream did not regenerate headers via autoheader which caused the
# newly added HAVE_LT_DLADVISE_INIT conditional to be omitted which is
# necessary to turn on the lt_dladvise* functions which is necessary
# to address bz #689045, (unresolved link errors for perl & python)
Patch3: freeradius-lt-dladvise.patch

fixed in freeradius-2.1.10-5.el6

John,
could you please write a few key words to this bug into the Technical Notes field so I can document it in the erratum. If possible use the CCFR structure, of course only where it makes sense.

Thanks,

Florian

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause
    What actions or circumstances cause this bug to present.
Consequence
    What happens when the bug presents.
Fix
    What was done to fix the bug.
Result
    What now happens when the actions or circumstances above occur.
    Note: this is not the same as the bug doesn’t present anymore.

Cause:

If the rlm_perl or rlm_python module is utilized in the FreeRADIUS server to respectively execute perl or python code within the context of the FreeRADIUS server the perl or python interpreter may throw errors due to unresolved symbols encountered by the dynamic loader if the loaded perl or python loads external perl or python native modules (perl or python modules written in C and provided as .so objects).

Consequence:

The perl or python code being invoked by the FreeRADIUS server will throw an error and fail to execute, which causes the FreeRADIUS server to fail to start.

Fix:

The dynamic loader has an option which allows loaded modules to globally export their symbols. However this feature must be explicitly turned on via lt_dladvise. The building of FreeRADIUS was patched to assure lt_dladvise was enabled.

Result:

rlm_perl and rlm_python FreeRADIUS modules which cause external C based perl or python native modules to load are now successfully loaded and the FreeRADIUS server successfully starts in this configuration.

(In reply to comment #12)
> Cause:
> 
> If the rlm_perl or rlm_python module is utilized in the FreeRADIUS server to
> respectively execute perl or python code within the context of the FreeRADIUS
> server the perl or python interpreter may throw errors due to unresolved
> symbols encountered by the dynamic loader if the loaded perl or python loads
> external perl or python native modules (perl or python modules written in C and
> provided as .so objects).
> 
> Consequence:
> 
> The perl or python code being invoked by the FreeRADIUS server will throw an
> error and fail to execute, which causes the FreeRADIUS server to fail to start.
> 
> Fix:
> 
> The dynamic loader has an option which allows loaded modules to globally export
> their symbols. However this feature must be explicitly turned on via
> lt_dladvise. The building of FreeRADIUS was patched to assure lt_dladvise was
> enabled.
> 
> Result:
> 
> rlm_perl and rlm_python FreeRADIUS modules which cause external C based perl or
> python native modules to load are now successfully loaded and the FreeRADIUS
> server successfully starts in this configuration.

Perfect, many thanks

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0610.html