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.
