Re: [gentoo-user] Gentoo chroot with old glibc
Am Montag, 4. Januar 2021, 13:57:37 EET schrieb Thomas Mueller: > > > That's what I did: I found a 2017 stage3 with a still older glibc and > > > managed to upgrade to a 2020 gentoo while masking the last glibc > > > versions. That was tricky because I had to git-checkout intermediate > > > versions of the portage tree in order to deal with the EAPI changes but > > > I have a working chroot now. Thanks. > > > > That's the easy way to do it, yes. > > > > The hard way is to treat this as a cross-compilation problem and bootstrap > > your own stages from scratch. Instructions would be a bit longer... > > > > Andreas K. Hüttel > > I have looked through crossdev. Is that what it would take to cross-compile > and bootstrap stages from scratch? > > Could that be done from (instead of an old glibc) musl, uClibc, or FreeBSD > or NetBSD? In principle yes, but every experimental piece can add more problems. It's probably best to start with a base that is as boring as possible. What crossdev does is (simplified) * "create" (as symlinks) ebuilds for cross-compiler, cross-binutils, and target glibc * build cross-compiler, cross-binutils, and target glibc * installs a wrapper for emerge that uses these For example, you end up on an amd64 system with an additional directory /usr/ riscv64-unknown-linux-gnu that contains * a gcc that runs on amd64 (CBUILD) but generates code for riscv64 (CTARGET) * a binutils that runs on amd64 but works with files for riscv64 * a glibc for riscv64 Then, using commands like riscv64-unknown-linux-gnu-emerge -av @system you can build in /usr/riscv64-unknown-linux-gnu pieces of the target system. This works only in a very limited way, since many upstream build systems do not support cross-compiling. However, with some patience you can get to the point where the directory can be tarred up and used as a chroot on the target architecture. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Gentoo chroot with old glibc
> > That's what I did: I found a 2017 stage3 with a still older glibc and > > managed to upgrade to a 2020 gentoo while masking the last glibc > > versions. That was tricky because I had to git-checkout intermediate > > versions of the portage tree in order to deal with the EAPI changes but > > I have a working chroot now. Thanks. > That's the easy way to do it, yes. > The hard way is to treat this as a cross-compilation problem and bootstrap > your own stages from scratch. Instructions would be a bit longer... > Andreas K. Hüttel I have looked through crossdev. Is that what it would take to cross-compile and bootstrap stages from scratch? Could that be done from (instead of an old glibc) musl, uClibc, or FreeBSD or NetBSD? Tom
Re: [gentoo-user] Gentoo chroot with old glibc
Am Mittwoch, 1. Juli 2020, 03:30:59 CEST schrieb Thomas Mueller: > > > That's what I did: I found a 2017 stage3 with a still older glibc and > > > managed to upgrade to a 2020 gentoo while masking the last glibc > > > versions. That was tricky because I had to git-checkout intermediate > > > versions of the portage tree in order to deal with the EAPI changes but > > > I have a working chroot now. Thanks. > > > > That's the easy way to do it, yes. > > > > The hard way is to treat this as a cross-compilation problem and bootstrap > > your own stages from scratch. Instructions would be a bit longer... > > > > Andreas K. Hüttel > > I have looked through crossdev. Is that what it would take to cross-compile > and bootstrap stages from scratch? > > Could that be done from (instead of an old glibc) musl, uClibc, or FreeBSD > or NetBSD? It could be done from anywhere to anywhere in principle. (Like, building an old-glibc x86 stage on an arm64 machine...) This is how I bootstrapped the first riscv stages. (Yes I know we need newer ones...) But I don't claim it was a straightforward process. Took some time. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Gentoo chroot with old glibc
> > That's what I did: I found a 2017 stage3 with a still older glibc and > > managed to upgrade to a 2020 gentoo while masking the last glibc > > versions. That was tricky because I had to git-checkout intermediate > > versions of the portage tree in order to deal with the EAPI changes but > > I have a working chroot now. Thanks. > That's the easy way to do it, yes. > The hard way is to treat this as a cross-compilation problem and bootstrap > your own stages from scratch. Instructions would be a bit longer... > Andreas K. Hüttel I have looked through crossdev. Is that what it would take to cross-compile and bootstrap stages from scratch? Could that be done from (instead of an old glibc) musl, uClibc, or FreeBSD or NetBSD? Tom
Re: [gentoo-user] Gentoo chroot with old glibc
On June 30, 2020 1:26:48 AM PDT, "Andreas K. Huettel" wrote: >> That's what I did: I found a 2017 stage3 with a still older glibc and >> managed to upgrade to a 2020 gentoo while masking the last glibc >> versions. That was tricky because I had to git-checkout intermediate >> versions of the portage tree in order to deal with the EAPI changes >but >> I have a working chroot now. Thanks. > >That's the easy way to do it, yes. > >The hard way is to treat this as a cross-compilation problem and >bootstrap >your own stages from scratch. Instructions would be a bit longer... The medium way to do it is to use portage's ability to install packages to a different root directory. Which still has its caveats and challenges but generally avoids EAPI mismatches. LMP
Re: [gentoo-user] Gentoo chroot with old glibc
> That's what I did: I found a 2017 stage3 with a still older glibc and > managed to upgrade to a 2020 gentoo while masking the last glibc > versions. That was tricky because I had to git-checkout intermediate > versions of the portage tree in order to deal with the EAPI changes but > I have a working chroot now. Thanks. That's the easy way to do it, yes. The hard way is to treat this as a cross-compilation problem and bootstrap your own stages from scratch. Instructions would be a bit longer... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Gentoo chroot with old glibc
Le 21/06/2020 à 22:03, Michael a écrit : I hadn't understood you wanted a current state of an OS, plus current system and other packages, BUT with a deprecated version of glibc. I thought you would be OK to use a stage 3 from back then as it was in its totality, frozen in time, with no updates or backported packages. Yes, I need up-to-date or near-up-to-date build tools like cmake and gcc. However, since you managed to hold back glibc while updating everything else, you have proven what you wanted could be done! I would think this on its own is a feat worth a HowTo. :-) So far gentoo doesn't complain, besides keeping remind me my installed glibc is masked. But it's a quite minimalist system. I found the existing HowTo 'Update Old Gentoo'[1] useful for setting this up. I [1] https://wiki.gentoo.org/wiki/User:NeddySeagoon /HOWTO_Update_Old_Gentoo -- Hervé
Re: [gentoo-user] Gentoo chroot with old glibc
Le 21/06/2020 à 23:08, Rich Freeman a écrit : On Fri, Jun 19, 2020 at 5:19 PM Hervé Guillemet wrote: Or do you have any suggestion for alternatives to this gentoo chroot ? (I'd prefer avoid installing some CentOS or Ubuntu as virtual guests). You're of course free to do it any way you wish, but if I wanted to create packages for various distros, I'd probably just follow their instructions for doing so. If you're making Ubuntu 16.04 packages I suspect it would be just a lot less fuss all around to do it from an Ubuntu 16.04 container, and so on. And if you're just building binaries and creating tarballs with them, well, why? If people want to manually deal with stuff the source is already fine. If they want the benefits of a package manager they're going to want packages. And if you're hoping to encourage distros to do the packaging for you, they're probably only going to do that from source anyway. In my case the application is a Java software embedding some native components. I don't want to limit the target system to some specific distros and specific versions, I just want the software to run on a large variety of linux boxes. All I have to do is to avoid linking with too recent libc and libstdc++. Version 2.29+ of libc is particularly annoying because they introduce new version of pow(), log() and exp()... so any simple mathematical library compiled with 2.29+ won't run on linux distro using 2.28-. As for the packaging, I'm using a jlink image in a tarball, and will probably use jpackage soon. I imagine most distros have a fairly straightforward packaging system, and I suspect a lot of CI systems have plugins to churn out packages for them automatically. So why maintain some Gentoo chroot and carefully curate every single library on them to match some entirely different distro? You're going to run into stuff where Gentoo doesn't have the version you need in the repo, and you'll be fighting auto updates, and so on. But, sure, you can get Gentoo to install whatever you want as long as you don't mind manually picking packages, or maintaining your own repo where you carefully curate this stuff. Thanks for the suggestion. I believe my local build system with the chroot is enough for my current needs but I'll probably have to use a CI system if it becomes untractable or decide to use target distro packaging system. -- Hervé
Re: [gentoo-user] Gentoo chroot with old glibc
On Fri, Jun 19, 2020 at 5:19 PM Hervé Guillemet wrote: > > Or do you have any suggestion for alternatives to this gentoo chroot ? > (I'd prefer avoid installing some CentOS or Ubuntu as virtual guests). You're of course free to do it any way you wish, but if I wanted to create packages for various distros, I'd probably just follow their instructions for doing so. If you're making Ubuntu 16.04 packages I suspect it would be just a lot less fuss all around to do it from an Ubuntu 16.04 container, and so on. And if you're just building binaries and creating tarballs with them, well, why? If people want to manually deal with stuff the source is already fine. If they want the benefits of a package manager they're going to want packages. And if you're hoping to encourage distros to do the packaging for you, they're probably only going to do that from source anyway. I imagine most distros have a fairly straightforward packaging system, and I suspect a lot of CI systems have plugins to churn out packages for them automatically. So why maintain some Gentoo chroot and carefully curate every single library on them to match some entirely different distro? You're going to run into stuff where Gentoo doesn't have the version you need in the repo, and you'll be fighting auto updates, and so on. But, sure, you can get Gentoo to install whatever you want as long as you don't mind manually picking packages, or maintaining your own repo where you carefully curate this stuff. -- Rich
Re: [gentoo-user] Gentoo chroot with old glibc
On Sunday, 21 June 2020 20:43:59 BST Hervé Guillemet wrote: > Le 21/06/2020 à 19:06, Michael a écrit : > >> I need to distribute some linux binaries and the one built with my > >> up-to-date gentoo sytem won't run on distributions using older glibc. > >> > >> My idea is too maintain a gentoo chroot dedicated for compiling my > >> binaries which would (package.)mask recent versions of glibc and gcc > >> ebuilds. > >> > >> What's the better way to go ? If I start with some of the stage3 > >> available for download, I won't be able to downgrade the glibc. > >> > >> Or do you have any suggestion for alternatives to this gentoo chroot ? > >> (I'd prefer avoid installing some CentOS or Ubuntu as virtual guests). > > > > Once you chroot, you're in the chrooted env. As long as you have a stage > > 3 > > old enough to contain the requisite glibc, you should be good to go: > > > > http://gentoo.osuosl.org/releases/amd64/ > > That's what I did: I found a 2017 stage3 with a still older glibc and > managed to upgrade to a 2020 gentoo while masking the last glibc > versions. That was tricky because I had to git-checkout intermediate > versions of the portage tree in order to deal with the EAPI changes but > I have a working chroot now. Thanks. I hadn't understood you wanted a current state of an OS, plus current system and other packages, BUT with a deprecated version of glibc. I thought you would be OK to use a stage 3 from back then as it was in its totality, frozen in time, with no updates or backported packages. However, since you managed to hold back glibc while updating everything else, you have proven what you wanted could be done! I would think this on its own is a feat worth a HowTo. :-) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Gentoo chroot with old glibc
Le 21/06/2020 à 19:06, Michael a écrit : I need to distribute some linux binaries and the one built with my up-to-date gentoo sytem won't run on distributions using older glibc. My idea is too maintain a gentoo chroot dedicated for compiling my binaries which would (package.)mask recent versions of glibc and gcc ebuilds. What's the better way to go ? If I start with some of the stage3 available for download, I won't be able to downgrade the glibc. Or do you have any suggestion for alternatives to this gentoo chroot ? (I'd prefer avoid installing some CentOS or Ubuntu as virtual guests). Once you chroot, you're in the chrooted env. As long as you have a stage 3 old enough to contain the requisite glibc, you should be good to go: http://gentoo.osuosl.org/releases/amd64/ That's what I did: I found a 2017 stage3 with a still older glibc and managed to upgrade to a 2020 gentoo while masking the last glibc versions. That was tricky because I had to git-checkout intermediate versions of the portage tree in order to deal with the EAPI changes but I have a working chroot now. Thanks. -- Hervé
Re: [gentoo-user] Gentoo chroot with old glibc
On Friday, 19 June 2020 22:19:39 BST Hervé Guillemet wrote: > Hello, > > I need to distribute some linux binaries and the one built with my > up-to-date gentoo sytem won't run on distributions using older glibc. > > My idea is too maintain a gentoo chroot dedicated for compiling my > binaries which would (package.)mask recent versions of glibc and gcc > ebuilds. > > What's the better way to go ? If I start with some of the stage3 > available for download, I won't be able to downgrade the glibc. > > Or do you have any suggestion for alternatives to this gentoo chroot ? > (I'd prefer avoid installing some CentOS or Ubuntu as virtual guests). Once you chroot, you're in the chrooted env. As long as you have a stage 3 old enough to contain the requisite glibc, you should be good to go: http://gentoo.osuosl.org/releases/amd64/ signature.asc Description: This is a digitally signed message part.
[gentoo-user] Gentoo chroot with old glibc
Hello, I need to distribute some linux binaries and the one built with my up-to-date gentoo sytem won't run on distributions using older glibc. My idea is too maintain a gentoo chroot dedicated for compiling my binaries which would (package.)mask recent versions of glibc and gcc ebuilds. What's the better way to go ? If I start with some of the stage3 available for download, I won't be able to downgrade the glibc. Or do you have any suggestion for alternatives to this gentoo chroot ? (I'd prefer avoid installing some CentOS or Ubuntu as virtual guests). -- Hervé
