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@deployingradius.com> wrote:
On Dec 20, 2017, at 8:39 AM, kiran kumar <kirankumar9856@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