FreeRADIUS 3.0: 3rd party module build structure?
Hi, I'm currently trying to migrate a FreeRADIUS 2.x config to the new 3.0 version. I have a few custom rlm_* modules that I want to compile against the 3.0 sources. Previously, I had a Makefile similar to this: FR_SOURCE = $(HOME)/src/freeradius TARGET = rlm_omapi SRCS = rlm_omapi.c RLM_DIR = $(FR_SOURCE)/src/modules/rlm_example/ top_builddir = $(FR_SOURCE)/ include $(FR_SOURCE)/src/modules/rules.mak RLM_CFLAGS = -I/server/dhcp/server/include -I/server/dhcp/src/isc-dhcp/bind/include RLM_LDFLAGS = -L/server/dhcp/server/lib -ldhcpctl -lomapi -ldns -lisc This way I got "magically working" targets to build and install my module. However, now the build system was changed for good and I cannot really figure out how to achieve the same effect. (In particular, the "rules.mak" file is apparently "No longer needed" since 80f92e5aee, Feb 27 2013.) Is there an easy way so I don't have to write out all the long libtool command lines myself? Any help is appreciated! Julius
Julius Plenz wrote:
I'm currently trying to migrate a FreeRADIUS 2.x config to the new 3.0 version. I have a few custom rlm_* modules that I want to compile against the 3.0 sources.
It should be *very* simple. See the examples in the other modules. Previously, I had a Makefile similar to this:
FR_SOURCE = $(HOME)/src/freeradius TARGET = rlm_omapi SRCS = rlm_omapi.c
RLM_DIR = $(FR_SOURCE)/src/modules/rlm_example/ top_builddir = $(FR_SOURCE)/ include $(FR_SOURCE)/src/modules/rules.mak
RLM_CFLAGS = -I/server/dhcp/server/include -I/server/dhcp/src/isc-dhcp/bind/include RLM_LDFLAGS = -L/server/dhcp/server/lib -ldhcpctl -lomapi -ldns -lisc
This way I got "magically working" targets to build and install my module. However, now the build system was changed for good and I cannot really figure out how to achieve the same effect.
Copy an "all.mk" from another module, and set the relevant flags. Notice it's a *lot* simpler than before: TARGET = rlm_omapi.la SRCS = rlm_omapi.c TGT_CFLAGS = -I/server/dhcp/server/include -I/server/dhcp/src/isc-dhcp/bind/include TGT_LDFLAGS = -L/server/dhcp/server/lib -ldhcpctl -lomapi -ldns -lisc
(In particular, the "rules.mak" file is apparently "No longer needed" since 80f92e5aee, Feb 27 2013.)
Yes. We've completely re-done the build system. It's very nice.
Is there an easy way so I don't have to write out all the long libtool command lines myself?
We've gotten rid of libtool and libltdl completely. Life is *much* easier. Alan DeKok.
Hi, Alan! * Alan DeKok <aland@deployingradius.com> [2014-02-27 22:28]:
Copy an "all.mk" from another module, and set the relevant flags. Notice it's a *lot* simpler than before:
TARGET = rlm_omapi.la SRCS = rlm_omapi.c TGT_CFLAGS = -I/server/dhcp/server/include -I/server/dhcp/src/isc-dhcp/bind/include TGT_LDFLAGS = -L/server/dhcp/server/lib -ldhcpctl -lomapi -ldns -lisc
Yes, I got so far. But I'm developing the module in a separate repository outside the FreeRADIUS sources (e.g. I have ~/src/rlm_omapi and ~/src/freeradius). I'd like to include some makefile from the FreeRADIUS source tree without the need to copy my module into the source tree under src/modules in order to compile it there. Is that possible?
We've gotten rid of libtool and libltdl completely. Life is *much* easier.
Good riddance :-) Julius
On 27 Feb 2014, at 21:58, Julius Plenz <plenz@cis.fu-berlin.de> wrote:
Hi, Alan!
* Alan DeKok <aland@deployingradius.com> [2014-02-27 22:28]:
Copy an "all.mk" from another module, and set the relevant flags. Notice it's a *lot* simpler than before:
TARGET = rlm_omapi.la SRCS = rlm_omapi.c TGT_CFLAGS = -I/server/dhcp/server/include -I/server/dhcp/src/isc-dhcp/bind/include TGT_LDFLAGS = -L/server/dhcp/server/lib -ldhcpctl -lomapi -ldns -lisc
Yes, I got so far. But I'm developing the module in a separate repository outside the FreeRADIUS sources (e.g. I have ~/src/rlm_omapi and ~/src/freeradius). I'd like to include some makefile from the FreeRADIUS source tree without the need to copy my module into the source tree under src/modules in order to compile it there. Is that possible?
You can pull in the boiler make files if you really want. Else you could add it as a git submodule. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Julius Plenz wrote:
Yes, I got so far. But I'm developing the module in a separate repository outside the FreeRADIUS sources (e.g. I have ~/src/rlm_omapi and ~/src/freeradius).
That's no longer supported. It's the one downside to having a build system that (a) works, and (b) it's insane.
I'd like to include some makefile from the FreeRADIUS source tree without the need to copy my module into the source tree under src/modules in order to compile it there. Is that possible?
No. This isn't all bad. Just build the entire server. On my laptop, "make -j 4" takes about 8 seconds. Alan DeKok.
Hi, Alan! * Alan DeKok <aland@deployingradius.com> [2014-03-02 17:17]:
Yes, I got so far. But I'm developing the module in a separate repository outside the FreeRADIUS sources (e.g. I have ~/src/rlm_omapi and ~/src/freeradius).
That's no longer supported. It's the one downside to having a build system that (a) works, and (b) it's insane.
I went with Arran's suggestion and just include it as a Git submodule under src/modules. I can compile the module in principle now. However, the linking stage is not working as it was before. I pull in a bunch of symbols from static .a libraries (eg. `libisc.a'). However, the rlm_omapi.so object I get in `lib/modules' after linking (and installing it) does not contain the code for these symbols, and `nm' shows "U", meaning unresolved (it should be "T", included in the text section, so there's actual code for this symbol in the object). Appropriately, the server complains about missing symbols at startup. I'm not sure where the error occurs. If I was using regular `ld', I'd try using the `--whole-archive' option to simply lump together all the .a files in the .so object. -- However, including this switch in the SRC_LDFLAGS does not have any noticable effect. For reference, here is my `all.mk': TARGET := rlm_omapi.a SOURCES := rlm_omapi.c SRC_CFLAGS := -I$(HOME)/... SRC_LDFLAGS := -L$(HOME)/... -ldhcpctl -lomapi -ldns -lisc I cannot really find out what's going on during the "LINK build/lib/rlm_omapi.la" phase, even when using "make VERBOSE=1". Any hints appreciated! Thanks, Julius
Julius Plenz wrote:
However, the linking stage is not working as it was before. I pull in a bunch of symbols from static .a libraries (eg. `libisc.a'). However, the rlm_omapi.so object I get in `lib/modules' after linking (and installing it) does not contain the code for these symbols, and `nm' shows "U", meaning unresolved (it should be "T", included in the text section, so there's actual code for this symbol in the object). Appropriately, the server complains about missing symbols at startup.
Hmm... linking static libraries to dynamic ones is not supported by most linkers. libtool has some *horrific* code to support this. I didn't add that to the v3 build, because it's crazy. There might be a different way, tho.
I'm not sure where the error occurs. If I was using regular `ld', I'd try using the `--whole-archive' option to simply lump together all the .a files in the .so object. -- However, including this switch in the SRC_LDFLAGS does not have any noticable effect.
It should be used if you set it.
For reference, here is my `all.mk':
TARGET := rlm_omapi.a SOURCES := rlm_omapi.c SRC_CFLAGS := -I$(HOME)/... SRC_LDFLAGS := -L$(HOME)/... -ldhcpctl -lomapi -ldns -lisc
You should use TGT_LDFLAGS instead of SRC_LDFLAGS.
I cannot really find out what's going on during the "LINK build/lib/rlm_omapi.la" phase, even when using "make VERBOSE=1".
It should print out everything it does. It just runs jlibtool with a bunch of arguments, and jlibtool uses those arguments to run the linker. Alan DeKok.
On 3 Mar 2014, at 14:22, Alan DeKok <aland@deployingradius.com> wrote:
Julius Plenz wrote:
However, the linking stage is not working as it was before. I pull in a bunch of symbols from static .a libraries (eg. `libisc.a'). However, the rlm_omapi.so object I get in `lib/modules' after linking (and installing it) does not contain the code for these symbols, and `nm' shows "U", meaning unresolved (it should be "T", included in the text section, so there's actual code for this symbol in the object). Appropriately, the server complains about missing symbols at startup.
Hmm... linking static libraries to dynamic ones is not supported by most linkers.
libtool has some *horrific* code to support this. I didn't add that to the v3 build, because it's crazy. There might be a different way, tho.
I'm not sure where the error occurs. If I was using regular `ld', I'd try using the `--whole-archive' option to simply lump together all the .a files in the .so object. -- However, including this switch in the SRC_LDFLAGS does not have any noticable effect.
It should be used if you set it.
For reference, here is my `all.mk':
TARGET := rlm_omapi.a SOURCES := rlm_omapi.c SRC_CFLAGS := -I$(HOME)/... SRC_LDFLAGS := -L$(HOME)/... -ldhcpctl -lomapi -ldns -lisc
You should use TGT_LDFLAGS instead of SRC_LDFLAGS.
I cannot really find out what's going on during the "LINK build/lib/rlm_omapi.la" phase, even when using "make VERBOSE=1".
It should print out everything it does. It just runs jlibtool with a bunch of arguments, and jlibtool uses those arguments to run the linker.
Out of interest why are you talking to the ISC DHCP server? I assume that's what you're doing... FreeRADIUS can act as a DHCP server itself. -Arran
Hi, Alan, Hi, Arran, * Arran Cudbard-Bell <a.cudbardb@freeradius.org> [2014-03-03 17:59]:
You should use TGT_LDFLAGS instead of SRC_LDFLAGS.
That was a valuable hint. After discovering many more errors that were not FreeRADIUS's fault, I got a shared object that will correctly load. Thanks for the help!
Out of interest why are you talking to the ISC DHCP server? I assume that's what you're doing...
FreeRADIUS can act as a DHCP server itself.
I saw the code. I am indeed dynamically inserting and removing DHCP mappings from a running ISC DHCP server. It's a PITA, but I don't necessarily have control over which DHCP server software is used, and this approach has been working very well and stable for a few years now. Thanks again for your help, Julius
On 3 Mar 2014, at 17:57, Julius Plenz <plenz@cis.fu-berlin.de> wrote:
Hi, Alan, Hi, Arran,
* Arran Cudbard-Bell <a.cudbardb@freeradius.org> [2014-03-03 17:59]:
You should use TGT_LDFLAGS instead of SRC_LDFLAGS.
That was a valuable hint. After discovering many more errors that were not FreeRADIUS's fault, I got a shared object that will correctly load. Thanks for the help!
Out of interest why are you talking to the ISC DHCP server? I assume that's what you're doing...
FreeRADIUS can act as a DHCP server itself.
I saw the code. I am indeed dynamically inserting and removing DHCP mappings from a running ISC DHCP server. It's a PITA, but I don't necessarily have control over which DHCP server software is used, and this approach has been working very well and stable for a few years now.
Thanks again for your help,
No problem. Fancy contributing the module? I can see it being useful for other people in your situation. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Julius Plenz