| 1 |
On Sunday, 21 June 2020 20:43:59 BST Hervé Guillemet wrote: |
| 2 |
> Le 21/06/2020 à 19:06, Michael a écrit : |
| 3 |
> >> I need to distribute some linux binaries and the one built with my |
| 4 |
> >> up-to-date gentoo sytem won't run on distributions using older glibc. |
| 5 |
> >> |
| 6 |
> >> My idea is too maintain a gentoo chroot dedicated for compiling my |
| 7 |
> >> binaries which would (package.)mask recent versions of glibc and gcc |
| 8 |
> >> ebuilds. |
| 9 |
> >> |
| 10 |
> >> What's the better way to go ? If I start with some of the stage3 |
| 11 |
> >> available for download, I won't be able to downgrade the glibc. |
| 12 |
> >> |
| 13 |
> >> Or do you have any suggestion for alternatives to this gentoo chroot ? |
| 14 |
> >> (I'd prefer avoid installing some CentOS or Ubuntu as virtual guests). |
| 15 |
> > |
| 16 |
> > Once you chroot, you're in the chrooted env. As long as you have a stage |
| 17 |
> > 3 |
| 18 |
> > old enough to contain the requisite glibc, you should be good to go: |
| 19 |
> > |
| 20 |
> > http://gentoo.osuosl.org/releases/amd64/ |
| 21 |
> |
| 22 |
> That's what I did: I found a 2017 stage3 with a still older glibc and |
| 23 |
> managed to upgrade to a 2020 gentoo while masking the last glibc |
| 24 |
> versions. That was tricky because I had to git-checkout intermediate |
| 25 |
> versions of the portage tree in order to deal with the EAPI changes but |
| 26 |
> I have a working chroot now. Thanks. |
| 27 |
|
| 28 |
|
| 29 |
I hadn't understood you wanted a current state of an OS, plus current system |
| 30 |
and other packages, BUT with a deprecated version of glibc. I thought you |
| 31 |
would be OK to use a stage 3 from back then as it was in its totality, frozen |
| 32 |
in time, with no updates or backported packages. |
| 33 |
|
| 34 |
However, since you managed to hold back glibc while updating everything else, |
| 35 |
you have proven what you wanted could be done! I would think this on its own |
| 36 |
is a feat worth a HowTo. :-) |
Archives