From nobody Fri Aug 18 16:17:24 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 4RS6VQ3yrqz4qkMT for ; Fri, 18 Aug 2023 16:18:06 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RS6VQ0ry8z3NNQ for ; Fri, 18 Aug 2023 16:18:06 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-523b066d7ceso1326585a12.2 for ; Fri, 18 Aug 2023 09:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692375481; x=1692980281; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0CwDgV2Wg3S7ZMNtP693pEIPe7WUcbq+pXntMeAej3o=; b=JljOhQ3sC1BTZBSIJADyan5RDvWl0HmFkRkFtXN04/St6rHXZBQ73hZiCsqAuNOLa0 LRuE4Qj6UENQPNYNizp4YqcFTr8vEkSm8W/2e5xO3EpJZfj/Cjvi4CJ/4cDd2t6PPGxU zqFmjJXNgNCgBfoVGnAOSVX/VRyPUX1vfMs4HO71DUYrfZPRWFGKnahZxTwqdSDXM4pG AzCibwfkJ3Qn7o2GUgIbtornBmdNrw+R3jrJhJVVUvK/jMkmpRpUJfHPCBtF5IqjtkQU Dws+fT3QuJwntRFx1GIf+QvLDma4iweqsbGL9Uwq7djdpzrV7fOhgK0OK5U6cKAMWlv4 BrSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692375481; x=1692980281; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0CwDgV2Wg3S7ZMNtP693pEIPe7WUcbq+pXntMeAej3o=; b=d03JK1kSSRNAtcUYhpzdizUWYhHI8uybHii95gGZLgOPw8O5McBe1Q96+q2XLFxuJV Ub/DET+BilUOy68VmjpbVE6MWd7FeyZH4O0+AxpL7tKuj0QM0t8d2wNL5WqJTvS4HSGi uCO3UCkZBbXG+8eGj3DaePFBGzsbND0J0ccoRRT68iZrlsvETdWFHTyzspHnuEan72oJ ObCf7+M+yIW7TFxxhn4Uha67B6f8s4iKfdalpxEy3GsjAz/d0xeckvmwwI0MuS1nRhwr Ntu+kk8s9lUJV4RpEX1M0YlrisIj6O61iVZ9Sle40QOIiLkc09ysP9r9ySyTHcZwkowG ZIAg== X-Gm-Message-State: AOJu0YzcJPkzdaFQzGtiImdccoILpc/TM9zCn5QmfoJSTn6CI0t1/3lY +7xEUfozZllQGgxucgdQtDvpZHZm3+98hVSC7lP934nYfu8= X-Google-Smtp-Source: AGHT+IFnyZP39EgyCPhcbDFpOsOeHmbcLFgDGh9HA0cMY8YZ7fO0Ak8J1NvTbhxOCjiyIfLLbfSP6w7mFWSeH0GBYW0= X-Received: by 2002:a17:907:c24e:b0:99c:b0c9:4ebb with SMTP id tj14-20020a170907c24e00b0099cb0c94ebbmr2561486ejc.48.1692375480562; Fri, 18 Aug 2023 09:18:00 -0700 (PDT) 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 References: In-Reply-To: From: Mario Marietto Date: Fri, 18 Aug 2023 18:17:24 +0200 Message-ID: Subject: Re: Building a Linuxulator userland from source To: Jose Quinteiro Cc: ports@freebsd.org Content-Type: multipart/alternative; boundary="00000000000058792b060334df5e" X-Rspamd-Queue-Id: 4RS6VQ0ry8z3NNQ X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --00000000000058792b060334df5e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable But if I have understood well,do you want to change the userland and you are sure to reach a better linux compatibility? I don't think you will be able to. The linuxulator is not perfect because it is bugged at a "low" level. Changing the userland it will remain bugged. On Fri, Aug 18, 2023 at 6:03=E2=80=AFPM Jose Quinteiro wrote: > 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 somewha= t > > 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 i= n > > 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=3Dlinux, are currently copy&pasted to > > every port needing them. I wanted to keep it simple while first tryin= g > > 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 everythin= g > > 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 an= y > > staging/packaging), but it *does* have some helpful hints. > > > > Cheers, Felix > > > > --=20 Mario. --00000000000058792b060334df5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
But if I have understood well,do you want to change the us= erland and you are sure to reach a better linux compatibility? I don't = think you will be able to. The linuxulator is not perfect because it is bug= ged at a "low" level. Changing the userland it will remain bugged= .

On Fri, Aug 18, 2023 at 6:03=E2=80=AFPM Jose Quinteiro <freebsd@quinteiro.org&g= t; wrote:
Amazin= g 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 whic= h now
> reached a state where I want to show it to and discuss it with fellow<= br> > ports hackers.
>
> First, a link to my feature branch (warning, will be rebased every now=
> and then):
> <https://github.com/Zirias/zfbsd-ports/co= mmits/linux>
>
> 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 i= t 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 >=C2=A0 =C2=A0exactly the Linux version emulated by the FreeBSD version = this will
>=C2=A0 =C2=A0run on. This should make it possible to run a lot more Lin= ux binaries
>=C2=A0 =C2=A0without relying on e.g. Linux jails.
> - When binaries don't work for missing Linux libraries, make it so= mewhat
>=C2=A0 =C2=A0easy 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 t= his cross
> toolchain, bootstrapping versions of binutils and gcc are needed to > build the initial glibc, these versions are suffixed "-bootstrap&= quot;.
>
> 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 >=C2=A0 =C2=A0expects PREFIX to be used as is by the upstream build syst= em. This
>=C2=A0 =C2=A0won't hold for building Linux packages, PREFIX must be= /compat/linux
>=C2=A0 =C2=A0for that, but passed to the upstream build system in DESTD= IR.
> - LIB_DEPENDS don't work, which could probably be solved in the >=C2=A0 =C2=A0framework. Right now, I'm using a hacky workaround to = define
>=C2=A0 =C2=A0LINLIB_DEPENDS and add it to both RUN_ and BUILD_DEPENDS.<= br> > - A lot of smaller things that *should* be provided by the framework,<= br> >=C2=A0 =C2=A0some of them probably by USES=3Dlinux, are currently copy&= amp;pasted to
>=C2=A0 =C2=A0every port needing them. I wanted to keep it simple while = first trying
>=C2=A0 =C2=A0to get it to work, so the framework isn't touched yet = at all.
> - Some stage-qa checks get confused, some (e.g. checking that everythi= ng
>=C2=A0 =C2=A0is stripped) don't work.
> - In my tests, "poudriere testport" failed at least on i386,= because it
>=C2=A0 =C2=A0mounts linprocfs on /compat/linux/proc and then tries to r= emove
>=C2=A0 =C2=A0/compat/linux (remove pre-existing PREFIX). To test the po= rts, I had
>=C2=A0 =C2=A0to slightly modify the testport script for now.
> - For the Linux headers, there should be a metaport picking the Linux<= br> >=C2=A0 =C2=A0version based on ${OSVERSION}. This doesn't exist yet,= Linux 4.4.x is
>=C2=A0 =C2=A0always used.
> - Building the final linux-gcc ports, I get weird error messages
>=C2=A0 =C2=A0directly to poudriere's terminal (they do NOT appear i= n the build
>=C2=A0 =C2=A0log!) like this:
>=C2=A0 =C2=A0 =C2=A0ELF interpreter /usr/lib/ld-linux.so.2 not found, e= rror 2
>=C2=A0 =C2=A0I have no idea where this comes from, so far I couldn'= t identify any
>=C2=A0 =C2=A0negative effect though.
>
> Acknowledgement: I found quite some useful info for doing this in the<= br> > "Linux from Scratch" book. Of course you can't just foll= ow the book
> (very different scenario, it assumes building on Linux and not doing a= ny
> staging/packaging), but it *does* have some helpful hints.
>
> Cheers, Felix
>



--
Mario.
--00000000000058792b060334df5e--