Upgrading to FreeRADIUS-3.x

kiran kumar kirankumar9856 at gmail.com
Fri Dec 29 09:58:19 CET 2017

We would like to stick with C++ modules as these are custom modules created
to meet the requirements and are verified. I have updated the module code
as per standards of FR-v3.x and got stuck with below issues.

In file included from /usr/include/freeradius/radiusd.h:28:0,
                 from rlm_module.cpp:1:
/usr/include/freeradius/libradius.h:190:25: error: '<anonymous>' declared
as a 'virtual' field
  unsigned int virtual : 1;    //!< for dynamic expansion
/usr/include/freeradius/libradius.h:612:64: error: expected ',' or '...'
before 'new'
 VALUE_PAIR *fr_cursor_replace(vp_cursor_t *cursor, VALUE_PAIR *new);
In file included from rlm_module.cpp:2:0:
/usr/include/freeradius/modules.h:67:19: error: expected unqualified-id
before 'typename'
  char const      *typename; //!< Type name e.g. "Auth-Type".
/usr/include/freeradius/modules.h:67:18: error: expected ';' at end of
member declaration
  char const      *typename; //!< Type name e.g. "Auth-Type".
/usr/include/freeradius/modules.h:67:27: error: expected
nested-name-specifier before ';' token
  char const      *typename; //!< Type name e.g. "Auth-Type".

looks like FR source code needs to be updated to make it compatible with
C++ modules.

On Wed, Dec 20, 2017 at 7:39 PM, Alan DeKok <aland at deployingradius.com>

> On Dec 20, 2017, at 8:39 AM, kiran kumar <kirankumar9856 at gmail.com> wrote:
> > We are upgrading FreeRADIUS from 2.x to 3.x, during our work around with
> > FreeRADIUS-2.x we have created modules in c/c++. Now we need to update
> > these modules as per FR-3.x standards but modules created in c++ code do
> > not get compiled (with below errors) even after re-structuring the module
> > as FR3.x standards.
>   Linking C++ libraries to a C program isn't really a good idea.  It might
> work, but C++ is very different from C.
> > /usr/include/freeradius/libradius.h:190:25: error: '<anonymous>'
> declared
> > as a 'virtual' field
> >  unsigned int virtual : 1;    //!< for dynamic expansion
> >                         ^
>   Hmm... all of the header files have "extern C" things which *should*
> tell your C++ compiler to compile the header in "C" mode.
> > Is it high necessary that FR-3.x modules are to be written only in
> c-code ?
>   No.
> > Is there any way to overcome this issue ?
>   If there's an issue with the headers, we can add patches in to help them
> compile with C++.
>   But there are a few related questions... why C++?  Why not C?  If it's
> not a lot of code, it should be possible to re-write it in C.
>   Also, why a custom module?  If it's useful code, it's good to send the
> code back so that everyone else can use it.
>   What you're doing now is really creating a private / proprietary fork of
> FreeRADIUS, and then asking us to support it.  That's not something we can
> really help you with.
>   Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/
> list/users.html

More information about the Freeradius-Users mailing list