FreeRADIUS 3.0: 3rd party module build structure?

[Alan DeKok]

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.