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 alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org netch...@freebsd.org : PGP 0x8F31830F9F2772BF
