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

On 10/3/25 17:45, Mark Johnston wrote:
> 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.

I backed all of it out for the time being, because testing with the github jobs pointed out
something funky[0] with the <sys/linker_set.h> for mach-o, and I don't want to stand in the
way of breaking cross-builds for this at the moment.

[0] https://github.com/kevans91/freebsd/actions/runs/18237117404/job/51932901152