FreeRADIUS 3.0: 3rd party module build structure?

[Julius Plenz]

Hi, Alan!

* Alan DeKok <aland at 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