Re: Building a Linuxulator userland from source

Am 2023-08-18 08:23, schrieb Felix Palmen:
> Hi all,
> 
> for the last two weeks, I've been working on a spike in ports which now
> reached a state where I want to show it to and discuss it with fellow
> ports hackers.
> 
> First, a link to my feature branch (warning, will be rebased every now
> and then):
> <https://github.com/Zirias/zfbsd-ports/commits/linux>

I haven't looked at it.

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/

> The goal is to create a replacement for the now antiquated linux-c7
> userland. While the classic approach would be to find another Linux

Nice goal.

> distribution that's not too much of a moving target and start
> "repackaging" that, I want to try something different: Build the
> required packages from source.

 From a technical point of view I consider this "interesting" and "fun". 
 From a goal-oriented perspective (get a more recent linux_base port in 
the tree) I would consider a binary-repackaging of a LTS distribution an 
interesting candidate. The new Enterprise Linux group 
(https://openela.org/news/hello_world/) seems only to want to provide 
source code, not binary packages. If they would provide bianry packages, 
I would consider them to be an interesting candidate.

> ** Why
> 
> It will be quite some work to do this, I'm not really sure about it yet
> (and how it would compare to the repackaging approach), so feasibility
> is yet to be decided. But I hope to get at least these two advantages:

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

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

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

One benefit I see is, that we can compile the userland to match the 
kernel interface we have.

> ** State
> 
> I just reached a state where I can build a working Linux-native GNU
> toolchain (binutils, glibc, gcc) for C and C++ on aarch64, amd64 and
> i386. From here on, it should be simpler, there are already two ports 
> in
> my branch (archivers/linux-bzip2 and archivers/linux-xz) using that
> native toolchain for building.
> 
> ** How
> 
> The native toolchain is built by a cross toolchain, the packages for
> this cross-toolchain are prefixed "lxcross-". For building this cross
> toolchain, bootstrapping versions of binutils and gcc are needed to
> build the initial glibc, these versions are suffixed "-bootstrap".
> 
> lxcross ports set PREFIX to ${LXCROSSBASE}, which defaults to
> ${LOCALBASE}/linux-cross. lxcross-*-bootstrap ports set PREFIX to
> ${LXBOOTSTRAP}, this one defaults to ${LXCROSSBASE}/bootstrap.
> 
> ** Open issues
> 
> This is an unordered list off my head, so most likely incomplete.
> 
[...]
> - A lot of smaller things that *should* be provided by the framework,
>   some of them probably by USES=linux, are currently copy&pasted to
>   every port needing them. I wanted to keep it simple while first 
> trying
>   to get it to work, so the framework isn't touched yet at all.

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.

Bye,
Alexander.

-- 
http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF