Re: gnulib & modules

[Daniel J. <dan...@gm...>]

Oh my, I think I made some false assumptions. You're right, we don't
need separate gnulib checkouts. Neither do we need a shared libgnu.

If we have a single gnulib checkout, and we add in (all) the gnulib
modules needed by "boot CLISP", the base CLISP modules and all other
CLISP modules (that we keep in our repository), and then link ...

1) "base CLISP" ("boot CLISP" + the base modules) against libgnu.a (by
   including libgnu.a in the linking set)

2) every "non base" module against that same libgnu.a (and resolving all
   dependencies, so probably a "relocatable object" produced by ld -r
   will be necessary here)

... then, because we're linking against a static library, the linker
will only pull in exactly the symbols (and code) it needs.

Thus "base CLISP" will not get "fatter" when adding gnulib modules due
to some (non base) CLISP module, and neither will we be including "too
much" in (non base) CLISP modules.

We still have duplicate code for overlapping functionality in "base"
and "non base", though (but I'd guess this won't be avoidable). Oh,
and the base linking set (the directory, not the executable) of course
thus contains the possibly fat libgnu.a (but disk space is cheap,
isn't it?)

And as far as I can see, this is - without the "relocatable object" -
exactly what we've been doing already, right? Or am I on the wrong
track with this?

(If only that insight came earlier, that would've saved me quite some
time and thinking in the last months)


> Even on linux - on LINUX, Carl! - it pulls in ioctl!

Hehe :)