Hello, 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. /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_attrefvnf_auth_status_monitor.cpp:3: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". Is it high necessary that FR-3.x modules are to be written only in c-code ? Is there any way to overcome this issue ? Thanks..
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.
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
On 29/12/2017, at 9:58 PM, kiran kumar <kirankumar9856@gmail.com> wrote:
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.
It is very difficult to claim that a module is verified if it is compiled against a new major version. I would say that the module is not verified anymore in that case. But, your arbitrary constraints are your own arbitrary constraints I guess… seems pretty silly, though.
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 ^
`virtual' is a reserved word in C++.
/usr/include/freeradius/libradius.h:612:64: error: expected ',' or '...' before 'new' VALUE_PAIR *fr_cursor_replace(vp_cursor_t *cursor, VALUE_PAIR *new); ^
`new’ is a reserved word in C++.
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". ^
`typename' is a reserved word in C++.
looks like FR source code needs to be updated to make it compatible with C++ modules.
There would need to be a patch where `virtual’, `new’, and `typename` are replaced with something else. That wouldn’t be an unwieldy task. You should be able to submit that. I don’t know that it would be accepted though. You’d need to change these once you’d updated the attr_flags struct: src/lib/dict.c:1777: flags.virtual = 1; src/main/xlat.c:1844: if (!vpt->tmpl_da->flags.virtual) { src/main/modcall.c:3083: if (attr->tmpl_da->flags.virtual) { src/main/modcall.c:3232: if ((vpt->type == TMPL_TYPE_ATTR) && vpt->tmpl_da->flags.virtual) { src/main/modcall.c:3450: if ((vpt->type == TMPL_TYPE_ATTR) && vpt->tmpl_da->flags.virtual) { src/main/modcall.c:3460: if ((vpt->type == TMPL_TYPE_ATTR) && vpt->tmpl_da->flags.virtual) { src/main/modcall.c:3674: if ((g->vpt->type == TMPL_TYPE_ATTR) && g->vpt->tmpl_da->flags.virtual) { src/main/modcall.c:3820: if ((g->vpt->type == TMPL_TYPE_ATTR) && g->vpt->tmpl_da->flags.virtual) { You’d also need to change the fr_cursor_replace implementation and declaration to not refer to `new’. Here’s what you’d need to change after updating the section_type_value_t struct: src/main/modules.c:1012: RDEBUG2("%s sub-section not found. Ignoring.", section_type_value[comp].typename); src/main/modules.c:1074: section_type_value[comp].typename, name2); src/main/modules.c:1115: section_type_value[comp].typename); src/main/modules.c:1136: section_type_value[comp].typename) == 0) { src/main/modules.c:1756: section_type_value[comp].typename); src/main/modules.c:1798: cs2 = cf_section_sub_find_name2(subcs, section_type_value[comp].typename, cf_pair_attr(cp)); src/main/modules.c:1813: for (type_cs = cf_subsection_find_next(subcs, NULL, section_type_value[comp].typename); src/main/modules.c:1815: type_cs = cf_subsection_find_next(subcs, type_cs, section_type_value[comp].typename)) { src/main/modules.c:1823: cs2 = cf_section_sub_find_name2(subcs, section_type_value[comp].typename, cf_section_name2(type_cs)); Note though - I have only looked at the v3.0.x branch. I have not considered v4.0.x. It looks like the virtual flag is used in a few more places there, etc. Looks like typename is not used outside the section_type_value_t struct definition though, so perhaps you’re in luck. Not sure what *other* issues would come up if you were able to solve the above. -- Nathan Ward
On Dec 29, 2017, at 3:58 AM, kiran kumar <kirankumar9856@gmail.com> wrote:
We would like to stick with C++ modules as these are custom modules created to meet the requirements and are verified.
i.e. they are YOUR modules. Not our modules. So it's not really our issue to fix them, is it? And I'll agree with Nathan here. If you're porting the modules from v2 to v3, they are no longer "verified".
I have updated the module code as per standards of FR-v3.x and got stuck with below issues.
If you're familiar with C++ you should be able to fix those issues. If you can't fix those issues, you should find someone (not us) who can.
looks like FR source code needs to be updated to make it compatible with C++ modules.
That's your problem, not ours. I'll repeat:
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.
If you want to send us a patch that changes names (virtual, new, etc.), we can take a look. But past that, it's your code, and your problem. If you're not willing to contribute the modules back to the community, then the community has no reason to help you. Alan DeKok.
participants (3)
-
Alan DeKok -
kiran kumar -
Nathan Ward