Re: git: 1953a12ee2cd - main - flua: support our flua modules in the bootstrap flua

On Fri, Oct 03, 2025 at 04:44:38PM -0500, Kyle Evans wrote:
> 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 <kevans@FreeBSD.org>
> > > AuthorDate: 2025-10-03 18:09:03 +0000
> > > Commit:     Kyle Evans <kevans@FreeBSD.org>
> > > 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?

I don't see any bootstrap build failures in an Ubuntu chroot after I
disable building libfreebsd.  Let me know if you'd like me to submit a
patch for that.