On 10/3/25 16:39, Mark Johnston wrote:
On Fri, Oct 03, 2025 at 06:10:35PM +0000, Kyle Evans wrote:
The branch main has been updated by kevans:
URL:
https://cgit.FreeBSD.org/src/commit/?id=1953a12ee2cde1afacb3e3f7612d89695c96e04f
commit 1953a12ee2cde1afacb3e3f7612d89695c96e04f
Author: Kyle Evans <[email protected]>
AuthorDate: 2025-10-03 18:09:03 +0000
Commit: Kyle Evans <[email protected]>
CommitDate: 2025-10-03 18:09:14 +0000
flua: support our flua modules in the bootstrap flua
This version builds every module into the flua binary itself, since all
of the bootstrap tools are built -DNO_SHARED. As a result, we also
cannot dlsym(), so we can't really discover the names of our newly
builtin modules. Instead, just build out a linker set with all of our
luaopen_*() functions to register everything up-front.
Building in all of the modules isn't strictly necessary, but it means
that we have an example of how to add a bootstrap module everywhere you
go and one doesn't need to consider whether bootstrap flua can use a
module when writing scripts. On my build machine, the consequence on
our binary size is an increase from around 1.6M -> 1.9M, which isn't
really that bad.
.lua modules can install into their usual path below $WORLDTMP/legacy
and we'll pick them up automagically by way of the ctor that sets up
LUA_PATH early on.
Reviewed by: bapt, emaste
Differential Revision: https://reviews.freebsd.org/D51890
This breaks cross-building from other OSes since linker.h and kenv.h
aren't available. I guess we can safely exclude those from the
bootstrap build? It could be done conditionally on ${.MAKE.OS} perhaps,
but it's probably better to be consistent.
Hi,
Hmm, yes- I think excluding libfreebsd and libjail doesn't make it much more
difficult to reason about what's available in the bootstrap flua.
re: cross-builds, yikes- I forgot that we'll end up bootstrapping flua there. I
bet it's also broken without libyaml and libucl here:
https://reviews.freebsd.org/D52894?
Thanks,
Kyle Evans
