On Oct 21, 2015, at 9:56 AM, Eran Pasternak <eran.pasternak@forescout.com> wrote:
First let me clarify that I use one machine for development (where I compile radius ) and another for testing (where I run radius). The problem was that on the testing machine, radclient tried to access the dictionary in a path different from the one defined in Make.inc (and src/include/radpath.h). Now, thanx to your reply, I understand the reason. In my development env, 'freeradius-devel' was not a softlink but an actual directory! Seems that in one of the earliest code-branching the actual content of the link was copied and since this directory is not *configured*, radpath.h in it wasn't updated - and of course this is the file used for compilation.
That would explain it.
So now I just have a question to better understand the usage of all these directories - please correct me if I'm wrong: /src/include - contains the source headers for development.
The source headers for the version you are currently building.
/src/freeradius-devel - is a softlink to this dir, which facilitates experimenting with APIs (or any header definitions) by allowing to create copies of the include dir. without altering all the c files.
No. It has nothing to do with altering C files. It's all about include file paths. We never install anything to /usr/include/freeradius-devel. So we can *guarantee* that there is no standard include path of /usr/include/freeradius-devel/. Which means that when the source code does: #include <freeradius-devel/foo.h> We can *guarantee* that the source code finds the header files from the build tree, and not any installed header files. If instead the source did: #include <freeradius/foo.h> We would have *no idea* whether the compiler picks /usr/include/freeradius/foo.h, or src/include/foo.h. And those files can be different.
/usr/include - the installed copy of the headers. This allows using their content for developing or changing modules on the machine itself.
Pretty much, yes. Alan DeKok.