Re: Building a Linuxulator userland from source

From: Alexander Leidinger <>
Date: Mon, 21 Aug 2023 23:25:36 UTC
Am 2023-08-18 11:26, schrieb Felix Palmen:
> Hi Alexander,
> thanks for commenting!
> * Alexander Leidinger <> [20230818 11:02]:
>> As the person who switched the linuxulator from redhat 4 or 5 to 
>> fedora and
>> mentored the people which moved forward to linux-c6 I have some info 
>> about
>> the design principles of the linux_base ports which you may or may not 
>> know
>> already:
> This might certainly be useful to check against. I think I do have some
> understanding, but so far only from looking at what existing ports are
> doing.
>> If it shall not be much of a moving target, I associate "not much 
>> work" with
>> it. This is somehow contradicting your approach with building from 
>> source in
>> my opinion. It also opens up the question if any issue is because of 
>> what we
>> do with it, or because of upstream. And this additionally to the 
>> complexity
>> if the issue is in our linuxulator (kernel side). This doesn't sound 
>> much
>> like "not much work".
> Yes, I see how "bug hunting" could be an issue. So far, I could stay
> *very* close to upstream in my ports, but yep, it's only the GNU
> toolchain, I will have to see where it leads.
>> > - Provide the newest GNU libs (glibc, libstdc++, ...) built against
>> >   exactly the Linux version emulated by the FreeBSD version this will
>> >   run on. This should make it possible to run a lot more Linux binaries
>> >   without relying on e.g. Linux jails.
>> I see a mismatch here. You want to have the newest ones, while the
>> distribution itself shall not be a much of a moving target.
> This seems to be a misunderstanding though. IMHO, for repackaging some
> distribution, this should not be a moving target, because otherwise you
> could have some unpleasant surprise like some glibc update suddenly
> requiring a newer Linux version that the FreeBSD kernel offers.
> With building from source, at least *this* can't be a problem, because
> the base libs will always be built with the "correct" version of the
> Linux headers.
>> > - When binaries don't work for missing Linux libraries, make it somewhat
>> >   easy to add them, maybe based on already existing FreeBSD ports.
>> This may be harder than you think. Or more easy than I think. The 
>> FreeBSD
>> ports will have stuff specific to FreeBSD which may not be needed for 
>> the
>> linux-on-FreeBSD-build. The building part may involve more hackery 
>> than the
>> FreeBSD port.
> Yes, I'm aware of that. It might require quite some work on the
> framework to make it actually easy. TBH, this is just an idea so far, I
> didn't really think about come concrete concept yet.
>> USE=linux is suited for the needs of a linux_base port. A linux_base 
>> port is
>> designed to integrate with the FreeBSD system (= fallthrough so 
>> FreeBSD
>> config if the config is a drop-in replacement for the linux config, 
>> e.g.
>> krb5.conf or hosts and such). What you need for building is on the 
>> other
>> hand a "pure" linux system without any fallthrough to FreeBSD, to make 
>> sure
>> you don't pollute the linux-build with FreeBSD stuff. This means at 
>> least a
>> chroot into some linux_dist-style port instead of a linux_base style 
>> port.
> 1.) Of course, Uses/ would need quite some switching to handle
> c7 as well as something new that works completely differently (maybe
> call it src). All still open issues.

I suggest to write a new Uses/ for this. Much more easy for you to 
do what you want, and less error prone and less QA to do for the 
existing linux_base stuff.

> 2.) Could you please elaborate how e.g. some config file "visible" to
> the Linux processes could "pollute" a Linux build? Besides, this could
> only affect files from base /etc I think...

Well... the config part was more to highlight what the linux_base ports 
use the fallthrough for. In case of building I worry more that some 
includes from /usr/local are used than anything else. Also some other 
stuff configure-runs might pick-up from the installed FreeBSD ports.


-- PGP 0x8F31830F9F2772BF  : PGP 0x8F31830F9F2772BF