Date: Fri, 18 Aug 2023 11:26:32 +0200 From: Felix Palmen <zirias@freebsd.org> To: ports@freebsd.org, emulation@freebsd.org Subject: Re: Building a Linuxulator userland from source Message-ID: <pusevat67254zxani3p26zpktfozyeopw6nm2gxbkjvq7o4d5h@573vplxfsmsq> In-Reply-To: <d1fdffa65d8d83018448ea2565bee397@Leidinger.net> References: <xcztahm3vu3bjghjqqxuoy2xabyjmyfq22jw6mkaaaqo7wa36s@fdq7dlvpuhlk> <d1fdffa65d8d83018448ea2565bee397@Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--c7u3piobwowdasdm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 a= nd > 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 kn= ow > already: > https://www.leidinger.net/blog/2011/08/29/howto-create-a-new-linux_base-p= ort/ > 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" w= ith > 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 complexi= ty > 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. >=20 > 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. >=20 > 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 t= he > 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=3Dlinux is suited for the needs of a linux_base port. A linux_base po= rt is > designed to integrate with the FreeBSD system (=3D 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 su= re > 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 --=20 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 --c7u3piobwowdasdm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iNUEABYKAH0WIQRpNhPVW79IN7ISOsxUreAGmHnyMQUCZN85Ql8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0Njkz NjEzRDU1QkJGNDgzN0IyMTIzQUNDNTRBREUwMDY5ODc5RjIzMQAKCRBUreAGmHny MeaaAP9KEek7KceZDDoTdPybvhE4YD8Q5zGudWY4aynbighgTgEAhCkG598fy6SH Im6u9YlZI2Oogs8JDY7X4Y1rR9rpSQs= =Q8GN -----END PGP SIGNATURE----- --c7u3piobwowdasdm--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?pusevat67254zxani3p26zpktfozyeopw6nm2gxbkjvq7o4d5h>