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>
wrote:
> 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