From nobody Fri Aug 18 16:03:15 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 4RS69V52xMz4qk4w for ; Fri, 18 Aug 2023 16:03:26 +0000 (UTC) (envelope-from freebsd@quinteiro.org) Received: from mx2.quinteiro.org (mx2.quinteiro.org [71.19.154.200]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RS69T2MCyz3L4K for ; Fri, 18 Aug 2023 16:03:25 +0000 (UTC) (envelope-from freebsd@quinteiro.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=quinteiro.org header.s=default header.b=eRNJswsY; spf=pass (mx1.freebsd.org: domain of freebsd@quinteiro.org designates 71.19.154.200 as permitted sender) smtp.mailfrom=freebsd@quinteiro.org; dmarc=none Received: from www.quinteiro.org (www.quinteiro.org [204.109.56.22]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx2.quinteiro.org (Postfix) with ESMTPS id 32E8F21D9A6 for ; Fri, 18 Aug 2023 16:03:17 +0000 (UTC) (envelope-from freebsd@quinteiro.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=quinteiro.org; s=default; t=1692374597; bh=IXi7Xm7xQOrGDaBDj9GlIEb5ellRORmoXcJd+fcT02s=; h=Date:Subject:To:References:From:In-Reply-To; b=eRNJswsY+N3pKCk5G06N1rRZXRu+ZxK+yiejbO73gCpBcINbAfkSRF4+mqgxFiBwg o1V3L9oXaNucaPqdToaUvX4LEL33ifNVlCUpvu0n2OKLs300e5bPwz73IU0ws4p9qf MjD+/ZSWZjkvQKfVSF3RHUMdIMqeoZBfLKqTxN1Y= Received: from [172.16.1.231] (157-131-78-27.fiber.dynamic.sonic.net [157.131.78.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by www.quinteiro.org (Postfix) with ESMTPSA id E577E2E89A for ; Fri, 18 Aug 2023 16:03:15 +0000 (UTC) Message-ID: Date: Fri, 18 Aug 2023 09:03:15 -0700 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 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: Building a Linuxulator userland from source To: ports@freebsd.org References: Content-Language: en-US From: Jose Quinteiro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[quinteiro.org:s=default]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[quinteiro.org:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[ports@freebsd.org]; ASN(0.00)[asn:47066, ipnet:71.19.154.0/24, country:US]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[quinteiro.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[ports@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RS69T2MCyz3L4K Amazing work. Thanks Felix! On 8/17/23 23:23, Felix Palmen wrote: > 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): > > > The goal is to create a replacement for the now antiquated linux-c7 > userland. While the classic approach would be to find another Linux > 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. > > ** 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: > > - 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. > - When binaries don't work for missing Linux libraries, make it somewhat > easy to add them, maybe based on already existing FreeBSD ports. > > ** 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. > > - Some trickery with PREFIX is currently needed. The ports framework > expects PREFIX to be used as is by the upstream build system. This > won't hold for building Linux packages, PREFIX must be /compat/linux > for that, but passed to the upstream build system in DESTDIR. > - LIB_DEPENDS don't work, which could probably be solved in the > framework. Right now, I'm using a hacky workaround to define > LINLIB_DEPENDS and add it to both RUN_ and BUILD_DEPENDS. > - 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. > - Some stage-qa checks get confused, some (e.g. checking that everything > is stripped) don't work. > - In my tests, "poudriere testport" failed at least on i386, because it > mounts linprocfs on /compat/linux/proc and then tries to remove > /compat/linux (remove pre-existing PREFIX). To test the ports, I had > to slightly modify the testport script for now. > - For the Linux headers, there should be a metaport picking the Linux > version based on ${OSVERSION}. This doesn't exist yet, Linux 4.4.x is > always used. > - Building the final linux-gcc ports, I get weird error messages > directly to poudriere's terminal (they do NOT appear in the build > log!) like this: > ELF interpreter /usr/lib/ld-linux.so.2 not found, error 2 > I have no idea where this comes from, so far I couldn't identify any > negative effect though. > > Acknowledgement: I found quite some useful info for doing this in the > "Linux from Scratch" book. Of course you can't just follow the book > (very different scenario, it assumes building on Linux and not doing any > staging/packaging), but it *does* have some helpful hints. > > Cheers, Felix >