I'm trying to cross-compile (from x86_64 linux to ARMv7a) for certain applications. The host was running Linux 4.4.0 and the target was running Linux 3.0.2
I was able to successfully build such application using cross-compile toolchain from Linaro
However, the problem occurred when I executed the binary
Fatal: kernel too old
After some researchs on the Internet, I discovered that workaround would be to also cross-compile glibc as well with --enable-kernel=VERSION option and another problem came with this option.
configure: WARNING: minimum kernel version reset to 3.2.0
Is there any workaround to set kernel version to the one older than 3.2.0?
Is there any workaround to set kernel version to the one older than 3.2.0?
No. Support for kernels below 3.2 was dropped in glibc-2.24, and you can't bring it back (short of reverting the commits that did it).
You will need to build glibc-2.23 or older.
Related
Let's say that I need to port an older version of the Linux kernel (3.2 for example) to a custom board. I'll be cross-compiling from a Ubuntu environment.
Will I need to be running a certain version of Ubuntu to successfully build a certain version of the kernel, or will I be fine with any version of Ubuntu?
Redhat 5 has the required 2.6.18 kernel but not the latest glibc, g++ and certainly no clang. The binary distribution doesn't run, complaining about glibc version.
Has anyone made an attempt to back port to old Linux? I could imagine cobbling together a frankensystem with an old kernel but new compilers and try to compile against old glibc or statically compile in some of new glibc but it seems like a fraught course.
Just wondering if anyone has tried and can offer guidance?
I'm thinking there must be a distro setup to do such builds. Anaconda, for example, includes lots of new technologies but works fine on Redhat 5. I wonder how they build it?
Update: Once you get some newer compilers working on RHEL5 it's still not possible to build Rust because it depends on a working binary of itself to bootstrap. See: https://github.com/rust-lang/rust/issues/9545#issuecomment-54865031
Anaconda packages are built against CentOS 5 (which is equivalent to Redhat 5). The important thing is to compile against an old enough glibc, as it is strictly forward compatible (as you saw). The version of glibc is typically tied to the version of the distro, so your best bet is to make a VM with CentOS 5 and build on that.
The version of the compiler used is not as important, and in fact in some cases it is necessary to use a newer compiler than the old one that comes with the system to get things to work. I have gcc 4.8 built for CentOS 5 which you can get with conda (conda install -c asmeurer gcc).
I hit this very issue this weekend, because Skylight supports Linux 2.6.18, including CentOS 5.10, and we use Rust in our agent.
Alex Crichton of the Rust core team was kind enough to get this working again by using CentOS 5.10 boxes for the build, which uses glibc 2.5 and Linux 2.6.18.
open-iscsi seems to require 2.6.x kernels and doesn't even compile with the newer (3.x) kernels, specifically 3.8.0 kernel.
Is it supposed to work with newer kernels?
Please see this:
https://groups.google.com/forum/#!topic/open-iscsi/_f4e13cIyNg
The kernel code in the open-iscsi dir only is for really old kernels.
Newer kernels have proper open-iscsi kernel support and you should use
those modules that come with your kernel/distro.
Do the newer kernels already have the support added to them?
My own end goal is to do a cross-compile to MIPS to be run on a 3.x kernel.
What are the iSCSI initiator software that are available to be used with newer linux kernels ?
Yes, linux kernel has open-iscsi support built into it now. When building the latest kernel, configure support for open-iscsi and you should have the module built after a successful build of the kernel.
I need to install old kernel into Kali (Debian like) distro. I need to run program which requires older kernel.
I downloaded kernel but the installation gives me too many errors. I was reading similar topics and watch the videos, but so far I am not successful.
I do not have experience with kernels. Is there .deb package for kernels or any other easier way to do it?
Can I use such old kernel for this distribution?
Thank you
The 2.4.33 kernel is pretty old. According to Debian's packaging files installing that old a kernel doesn't seem to be doable in wheezy. Attempting to install and run an old kernel outside the packaging system is not going to to work. All the "modern" libraries and applications will be broken when running the 2.4 kernel, as will the program (you need more than just a kernel for your program). If it were me, I'd set up a virtualization environment like VirtualBox or something similar and pick an old distro like CentOS 3.9 or an older Debian release (sarge or later). If that's not an option, you could always try and port the program to a more recent kernel.
I'm attempting to build a binary package that can be run on multiple Linux distributions. It's currently built on Ubuntu 10.04, but it fails on Ubuntu 8.04 with the following error:
./test: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./test)
./test: /usr/lib/libstdc.so.6: version `GLIBC_2.11' not found (required by ./test)
What's the preferred way to solve this problem? Is there a way to install an old glibc on a new box and build against it, or do I have to build on an old distribution? And if I build against an old glibc, will it work on a new glibc?
Or, alternatively, are there just some handy compiler flags or packages I could install to solve the problem?
The best solution I've found is to install a virtual machine running Debian stable, and build on that. Debian stable is old enough that any packages built with it will run on any other Debian-based distribution like Ubuntu. You may have to work around non-critical bugs that have been fixed in later versions of various software but not backported to Debian stable.
If you really want to make sure it runs on every recent distribution, you might also consider statically linking against a libC you select. However you may then still run into problems if you use features that are only provided by newer kernels (newer system calls e.g.).