From nobody Mon Aug 21 23:25:36 2023 X-Original-To: ports@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 4RV7rg2M41z4rRVN; Mon, 21 Aug 2023 23:25:55 +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 4RV7rf016Wz3M5Q; Mon, 21 Aug 2023 23:25:54 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=diCaKPYW; 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 1800C2D4; Tue, 22 Aug 2023 01:25:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1692660339; 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=iRzbLlQJ3s+qEvpPupHiobE6OpMI8APXd047EpasRvQ=; b=diCaKPYWuH0H72JpTrbFJ1dk5tbqaeK8ZTSNO3n6uo+LDs2sg6s+qSLpx6ekdfV33oq+r5 PrAUb3WfgJlLMTdPCUw9XExqTL5aI1ABcDeaToJIRA9UaEfbRlAp9vZg+SUxl2tS/qnTvB KYL/sNW0OhS3uyFVLW36GIp1EBUBTXYla1aiHRgDm5WOErsquHbOUZNfKzLfu3XhA9Tj0q EJuFyK/RehjhuK/h7CcRn9zFDhDFgiNXCVBGIs0gm9+VCJojYu9QxUq3kgaOt43Yigj5cv rtuISbBesUW2mZQcODrqPO/civogLkG2eRbZDEe12T89okazQYVxQSC7jMOboA== List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Date: Tue, 22 Aug 2023 01:25:36 +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: <67ea2b0e1f9ed5c695fb50c3d9a1d378@Leidinger.net> X-Sender: Alexander@Leidinger.net Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.90 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.90)[-0.902]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[emulation@freebsd.org,ports@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RV7rf016Wz3M5Q Am 2023-08-18 11:26, schrieb Felix Palmen: > Hi Alexander, > > thanks for commenting! > > * Alexander Leidinger [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