You are not logged in.
Pages: 1
For some reason, I need to run node.js binary from ArchLinux chrooted on a Centos 6 system which runs 2.6.32 kernel.
At some point (I don't remember when exactly) the code stopped to run with the infamous "FATAL: Kernel too old" message.
I tried to downgrade glibc, but apparently there were repackaging of some glibc dependencies, so it's not straightforward -U: it fails with "files exist in filesystem".
So I think that a solution is to make glibc-centos6 package which provides glibc.
But somehow getting the PKGBUILD with yaourt -G and then adding the custom PKGBUILD didn't work.
How do I proceed? How do I change package name without changing every place that relies on it being glibc?
Edit: apparently, according to https://sourceware.org/ml/libc-alpha/20 … 00010.html (search for 3.2 there), the lowest supported boundary is 3.2 since glibc-2.26
Last edited by nimnul (2018-06-02 19:57:18)
Offline
This is an interesting idea. :-)
It's much easier the other way round, using the Archlinux kernel with Centos 6 chroots.
That said I think you could use a project like:
https://aur.archlinux.org/cgit/aur.git/ … =glibc-git
as template.
Just add the --enable-kernel=2.6.32 to configure there.
I would actually use the same glibc version as in current Arch (not the git version):
pkgver=2.27
The following constructs should actually allow you to replace the C library in the chroot containing Archlinux:
provides=("glibc=${pkgver%%.r*}")
conflicts=('glibc')
Good luck. :-)
Offline
It's part of my https://github.com/nponeccop/vz project. Running chroots on Arch is not an option because Arch doesn't run on OpenVZ 6.
pkgver=2.27 is not an option because 2.25 is the last one which supports 2.6.32 kernel. 2.26 and later don't allow anything older than --enable-kernel=3.2 due to the linked changelog message.
I ended up setting a chroot on Arch with pacman pointing to Arch Linux Archive of 2017/08/01
Ideally I'd like to find a maintained version of pre-2.26 glibc and build from there. The best I could find is that CentOS 7 uses glibc-2.17. So I could try building their tree or something like that.
The problem is complicated by gcc-libs having a constraint on glibc. That is, I need a special version of gcc-libs as well, and who knows of what else. Imagine node using a new function from recent glibc, and so on.
Offline
Pages: 1