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
--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 <freebsd@quinteiro.o= rg> 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 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 <div dir=3D"ltr">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= .<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a= ttr">On Fri, Aug 18, 2023 at 6:03=E2=80=AFPM Jose Quinteiro <<a href=3D"= mailto:freebsd@quinteiro.org" target=3D"_blank">freebsd@quinteiro.org</a>&g= t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p= x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Amazin= g 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 whic= h 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=3D"https://github.com/Zirias/zfbsd-ports/commits/linux" re= l=3D"noreferrer" target=3D"_blank">https://github.com/Zirias/zfbsd-ports/co= mmits/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 i= t 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= > >=C2=A0 =C2=A0exactly the Linux version emulated by the FreeBSD version = this will<br> >=C2=A0 =C2=A0run on. This should make it possible to run a lot more Lin= ux binaries<br> >=C2=A0 =C2=A0without relying on e.g. Linux jails.<br> > - When binaries don't work for missing Linux libraries, make it so= mewhat<br> >=C2=A0 =C2=A0easy 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<b= r> > 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<b= r> > this cross-toolchain are prefixed "lxcross-". For building t= his cross<br> > toolchain, bootstrapping versions of binutils and gcc are needed to<br= > > build the initial glibc, these versions are suffixed "-bootstrap&= quot;.<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<b= r> >=C2=A0 =C2=A0expects PREFIX to be used as is by the upstream build syst= em. This<br> >=C2=A0 =C2=A0won't hold for building Linux packages, PREFIX must be= /compat/linux<br> >=C2=A0 =C2=A0for that, but passed to the upstream build system in DESTD= IR.<br> > - LIB_DEPENDS don't work, which could probably be solved in the<br= > >=C2=A0 =C2=A0framework. Right now, I'm using a hacky workaround to = define<br> >=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<br> >=C2=A0 =C2=A0every port needing them. I wanted to keep it simple while = first trying<br> >=C2=A0 =C2=A0to 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 everythi= ng<br> >=C2=A0 =C2=A0is stripped) don't work.<br> > - In my tests, "poudriere testport" failed at least on i386,= because it<br> >=C2=A0 =C2=A0mounts linprocfs on /compat/linux/proc and then tries to r= emove<br> >=C2=A0 =C2=A0/compat/linux (remove pre-existing PREFIX). To test the po= rts, I had<br> >=C2=A0 =C2=A0to slightly modify the testport script for now.<br> > - 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<br> >=C2=A0 =C2=A0always used.<br> > - Building the final linux-gcc ports, I get weird error messages<br> >=C2=A0 =C2=A0directly to poudriere's terminal (they do NOT appear i= n the build<br> >=C2=A0 =C2=A0log!) like this:<br> >=C2=A0 =C2=A0 =C2=A0ELF interpreter /usr/lib/ld-linux.so.2 not found, e= rror 2<br> >=C2=A0 =C2=A0I have no idea where this comes from, so far I couldn'= t identify any<br> >=C2=A0 =C2=A0negative 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 foll= ow the book<br> > (very different scenario, it assumes building on Linux and not doing a= ny<br> > staging/packaging), but it *does* have some helpful hints.<br> > <br> > Cheers, Felix<br> > <br> <br> </blockquote></div><br clear=3D"all"><br><span class=3D"gmail_signature_pre= fix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature">Mario.<br></d= iv> --00000000000058792b060334df5e--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2B1FSigHUvuYmFHSTmk01nfAcmckdTx-=1jB7PT8MhChg_bNiw>