Re: Building a Linuxulator userland from source

Hi Alexander,

thanks for commenting!

* Alexander Leidinger <Alexander@Leidinger.net> [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:
> https://www.leidinger.net/blog/2011/08/29/howto-create-a-new-linux_base-port/
> https://www.leidinger.net/blog/2011/09/01/howto-add-linux-infrastructure-ports-for-a-new-linux_base-port/

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/linux.mk 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.

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...

Cheers, Felix

-- 
 Felix Palmen <zirias@FreeBSD.org>     {private}   felix@palmen-it.de
 -- ports committer --                     {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231