Date: Fri, 18 Aug 2023 18:17:24 +0200 From: Mario Marietto <marietto2008@gmail.com> To: Jose Quinteiro <freebsd@quinteiro.org> Cc: ports@freebsd.org Subject: Re: Building a Linuxulator userland from source Message-ID: <CA%2B1FSigHUvuYmFHSTmk01nfAcmckdTx-=1jB7PT8MhChg_bNiw@mail.gmail.com> In-Reply-To: <b639ed9b-2a11-4457-dda8-89e6dd68d59c@quinteiro.org> References: <xcztahm3vu3bjghjqqxuoy2xabyjmyfq22jw6mkaaaqo7wa36s@fdq7dlvpuhlk> <b639ed9b-2a11-4457-dda8-89e6dd68d59c@quinteiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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 PM Jose Quinteiro <freebsd@quinteiro.org> 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): > > <https://github.com/Zirias/zfbsd-ports/commits/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 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 > > > > -- Mario. [-- Attachment #2 --] <div dir="ltr">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.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 18, 2023 at 6:03 PM Jose Quinteiro <<a href="mailto:freebsd@quinteiro.org" target="_blank">freebsd@quinteiro.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Amazing work. Thanks Felix!<br> <br> <br> On 8/17/23 23:23, Felix Palmen wrote:<br> > Hi all,<br> > <br> > for the last two weeks, I've been working on a spike in ports which now<br> > reached a state where I want to show it to and discuss it with fellow<br> > ports hackers.<br> > <br> > First, a link to my feature branch (warning, will be rebased every now<br> > and then):<br> > <<a href="https://github.com/Zirias/zfbsd-ports/commits/linux" rel="noreferrer" target="_blank">https://github.com/Zirias/zfbsd-ports/commits/linux</a>><br>; > <br> > The goal is to create a replacement for the now antiquated linux-c7<br> > userland. While the classic approach would be to find another Linux<br> > distribution that's not too much of a moving target and start<br> > "repackaging" that, I want to try something different: Build the<br> > required packages from source.<br> > <br> > ** Why<br> > <br> > It will be quite some work to do this, I'm not really sure about it yet<br> > (and how it would compare to the repackaging approach), so feasibility<br> > is yet to be decided. But I hope to get at least these two advantages:<br> > <br> > - Provide the newest GNU libs (glibc, libstdc++, ...) built against<br> > exactly the Linux version emulated by the FreeBSD version this will<br> > run on. This should make it possible to run a lot more Linux binaries<br> > without relying on e.g. Linux jails.<br> > - When binaries don't work for missing Linux libraries, make it somewhat<br> > easy to add them, maybe based on already existing FreeBSD ports.<br> > <br> > ** State<br> > <br> > I just reached a state where I can build a working Linux-native GNU<br> > toolchain (binutils, glibc, gcc) for C and C++ on aarch64, amd64 and<br> > i386. From here on, it should be simpler, there are already two ports in<br> > my branch (archivers/linux-bzip2 and archivers/linux-xz) using that<br> > native toolchain for building.<br> > <br> > ** How<br> > <br> > The native toolchain is built by a cross toolchain, the packages for<br> > this cross-toolchain are prefixed "lxcross-". For building this cross<br> > toolchain, bootstrapping versions of binutils and gcc are needed to<br> > build the initial glibc, these versions are suffixed "-bootstrap".<br> > <br> > lxcross ports set PREFIX to ${LXCROSSBASE}, which defaults to<br> > ${LOCALBASE}/linux-cross. lxcross-*-bootstrap ports set PREFIX to<br> > ${LXBOOTSTRAP}, this one defaults to ${LXCROSSBASE}/bootstrap.<br> > <br> > ** Open issues<br> > <br> > This is an unordered list off my head, so most likely incomplete.<br> > <br> > - Some trickery with PREFIX is currently needed. The ports framework<br> > expects PREFIX to be used as is by the upstream build system. This<br> > won't hold for building Linux packages, PREFIX must be /compat/linux<br> > for that, but passed to the upstream build system in DESTDIR.<br> > - LIB_DEPENDS don't work, which could probably be solved in the<br> > framework. Right now, I'm using a hacky workaround to define<br> > LINLIB_DEPENDS and add it to both RUN_ and BUILD_DEPENDS.<br> > - A lot of smaller things that *should* be provided by the framework,<br> > some of them probably by USES=linux, are currently copy&pasted to<br> > every port needing them. I wanted to keep it simple while first trying<br> > to get it to work, so the framework isn't touched yet at all.<br> > - Some stage-qa checks get confused, some (e.g. checking that everything<br> > is stripped) don't work.<br> > - In my tests, "poudriere testport" failed at least on i386, because it<br> > mounts linprocfs on /compat/linux/proc and then tries to remove<br> > /compat/linux (remove pre-existing PREFIX). To test the ports, I had<br> > to slightly modify the testport script for now.<br> > - For the Linux headers, there should be a metaport picking the Linux<br> > version based on ${OSVERSION}. This doesn't exist yet, Linux 4.4.x is<br> > always used.<br> > - Building the final linux-gcc ports, I get weird error messages<br> > directly to poudriere's terminal (they do NOT appear in the build<br> > log!) like this:<br> > ELF interpreter /usr/lib/ld-linux.so.2 not found, error 2<br> > I have no idea where this comes from, so far I couldn't identify any<br> > negative effect though.<br> > <br> > Acknowledgement: I found quite some useful info for doing this in the<br> > "Linux from Scratch" book. Of course you can't just follow the book<br> > (very different scenario, it assumes building on Linux and not doing any<br> > staging/packaging), but it *does* have some helpful hints.<br> > <br> > Cheers, Felix<br> > <br> <br> </blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Mario.<br></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2B1FSigHUvuYmFHSTmk01nfAcmckdTx-=1jB7PT8MhChg_bNiw>