The ability for a software vendor to use an out of the box (OS supplied package) FreeRadius server is a big deal. It means we don't have to distribute FreeRadius and maintain a bunch of stuff.
Why have modules at all (aside from the shared library benefits) if to use custom ones, you have to provide the whole package?
Well, you don't have to *distribute* the complete FreeRADIUS package. What you should however do is use the SRPM of the distribution(s) you are targeting to BUILD your package. You can do so by downloading the SRPM, 'install' it (i.e. unpack it), then adapt the SPEC or build script for the package to include your module in the build. If you look at the RHEL spec file for example, you will see that it builds many sub-packages, including the LDAP, Kerberos, PostgreSQL, MySQL and SQLite ones. If you design your module package such that it fits in with this model, you can simply distribute the output that contains your accounting module. It should however require the main package that is currently part of the distribution you are targeting. That way *you* follow what the distribution does. If it builds with -NDEBUG, *you* build with -NDEBUG. If it builds with -DEBUG, *you* do too. :-)
Yes, there are some risks in building the shared library object elsewhere (on our build machines, we take the same FreeRadius src as that of the OS rpm and build it, then use it on that same host when building our shared object files) but it can be done and is being done routinely in other applications. So I think the benefits outweigh the risks.
Ok. So you're already on the right track. You should however modify the distribution's SPEC file and build your module from there, not run a custom ./configure command, if that is what you're doing. :-) Stefan Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238