From nobody Fri Aug 18 09:02:46 2023 X-Original-To: emulation@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RRws36HbKz4qwXq; Fri, 18 Aug 2023 09:03:35 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RRws21lLCz3Svn; Fri, 18 Aug 2023 09:03:34 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=ro2cVDwT; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@Leidinger.net; dmarc=pass (policy=quarantine) header.from=leidinger.net Received: from webmail2.leidinger.net (roundcube.Leidinger.net [192.168.1.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: Alexander@Leidinger.net) by outgoing.leidinger.net (Postfix) with ESMTPSA id 962F65AE; Fri, 18 Aug 2023 11:02:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1692349399; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Qo8+rRkRgMo+/K+cjgD/OMqDJwaois8Ulm/Yz1OIw/Q=; b=ro2cVDwTBW8kalzF3RS5tvDKLO66xgGkUeb1FM00XeoQhjTQ3XqBqHVb/KNRkSQGFRnoRw QtXm9uL/dBZ8IgPBCyWthGcobbp5qtcSHKt03LsjvYJZUz28TZCqHekcpBK1OwCHXbSFlP BLKkFKChszIJKYd2AJZQNhC7lc6rFE9CNMjsHl7b5JJYhcE2THmVQKz9LxjzP8V1g91fiV FfT3eOvKrA1Ws5lyGmy8Z6ThlZ+yvp3ZE/UvGDp4LEcar5GCbuk4Z0is6rhM7ePVphePVe TNjbtWWx/PJ/cgk58wqBvlizI0SZ5zUs7MQfttIfIglta7fOQtmNozQMnRwtyA== List-Id: Development of Emulators of other operating systems List-Archive: https://lists.freebsd.org/archives/freebsd-emulation List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-emulation@freebsd.org MIME-Version: 1.0 Date: Fri, 18 Aug 2023 11:02:46 +0200 From: Alexander Leidinger To: ports@freebsd.org, emulation@freebsd.org Subject: Re: Building a Linuxulator userland from source In-Reply-To: References: Message-ID: X-Sender: Alexander@Leidinger.net Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [0.04 / 15.00]; SEM_URIBL_FRESH15(3.00)[openela.org:url]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.99)[-0.989]; NEURAL_HAM_LONG(-0.97)[-0.975]; MIME_GOOD(-0.10)[text/plain]; BAD_REP_POLICIES(0.10)[]; MLMMJ_DEST(0.00)[emulation@freebsd.org,ports@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; DMARC_POLICY_ALLOW(0.00)[leidinger.net,quarantine]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; R_DKIM_ALLOW(0.00)[leidinger.net:s=outgoing-alex]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(0.00)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4RRws21lLCz3Svn 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): > 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