Re: Building a Linuxulator userland from source
- Reply: Felix Palmen : "Re: Building a Linuxulator userland from source"
- In reply to: Felix Palmen : "Re: Building a Linuxulator userland from source"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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 <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. I suggest to write a new Uses/xxx.mk 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. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF