My distribution (Arch Linux) recently increased the minimum supported Linux kernel version for its toolchain. I am compiling a web application that I link statically and then upload to a web server, and the kernel version on the web server is too old for static libraries compiled with the new toolchain. (I get a segmentation fault when I try to run static binaries on the server.) Is there a way to compile applications using the GNU toolchain (GCC, binutils, glibc) such that features requiring newer kernel versions are left out?
Glibc compatibility is really only guaranteed in one direction. (Older binaries work on newer systems; vice versa, not necessarily so.)
To guarantee that your binaries work on older systems, compile linking with an older glibc. The easiest way to do this is to find an older distribution, but I would recommend setting up a "crosstool" or similar cross-compiling toolchain targeting a different libc than what your build system uses (and this allows for repeatable builds across hosts regardless of what the system is).
Thanks. I also found the --enable-kernel option to glibc, which enables working with earlier kernels.
Related
I'm developing and building applications for a various amount of platforms (linux x86, x86_64, arm, aarch64, sparc64, mips, powerpc, macos x86_64, freebsd x86_64, solaris x86_64 and of course Windows) and I was using a very old linux box (2014 Ubuntu) for all this cross-compilation.
I've recently decided that it was more than time to move to a more updated build environment as many tools were obsolete and could not be updated, so I've moved everything to a Ubuntu 22.04. All worked fine but then I hit the "glibc version hell" when I tried to run that on other boxes as glibc on that buildbox is 2.35.
So I've tried to get older glibc to compile and link against these as I'd really like to avoid linking everything static. But now, all the gcc that are build with Ubuntu have been with a "--with-sysroot=/" which, AFAII means I can't do anything. The --sysroot option is ignored by gcc which uses / for sysroot, no matter what.
I've seen a few answers saying "use old box to build" and that seems really insane to me. On my Mac or Windows, I can chose minimum (old) target platform, even if I build on W11 or Monterey. And obviously, the reason WHY I move to a new buildbox is to NOT use an old one and be stuck with obsolete tools :-).
I can probably use again ct-ng and rebuild all compilers, including native ones, but that seems really an overkill. Anybody with a better solution?
Thanks!
Seems that there is really no solution for what I'm looking for. I ended up almost re-inventing the wheel while trying to manually installing glibc. It was a faster option to use ct-ng and install cross-compilers from there, not using the stock ones provides with my distro.
I am thinking to download the GCC source code (latest version), compile it and develop all my applications with it.
Now, my doubts are related to what would happen if I need to interact with other libraries.
E.g. suppose you are using GCC 9 and you need to use external libraries installed in your Linux OS that have been build with GCC 5 (or older). Would there be any problem at runtime?
What other problems could you expect to experience using a compiler that is different from the system default one?
What are the relationships between the new compiler runtime and the runtime of the system default one?
I am using an ARM embedded system (ARM9) that running an embedded linux kernel. The kernel was compile with GCC 4.5.x with the eglibc.
Is there any harm running binary which are compiled code with GCC 4.8.x or newer which uses glibc.
I've read that you're not suppose to mix and match libc for stability reason. But as far as I understand they are both ABI compatible so they shouldn't be any problem.
Some of the code that I am using requires STD11 to compile correctly and thus I can't use GCC4.5.
The kernel was compile with GCC 4.5.x with the eglibc
The kernel build doesn't use GLIBC, so it's completely irrelevant what libc was (not) used to build the kernel.
Is there any harm running binary which are compiled code with GCC 4.8.x or newer which uses glibc.
No.
What occurs when the binary links against libc? It was linked against glibc when cross compiling but will link against eglibc that in sysroot.
In general, GLIBC and EGLIBC guarantee backward compatibility: that is, a binary linked against GLIBC-x.y will run fine against any GLIBC not older than x.y.
And EGLIBC's deviation from GLIBC is quite minimal. EGLIBC allowed for certain features to be disabled. A binary linked against EGLIBC-x.y will run just fine if at runtime it finds GLIBC that is not older than x.y (GLIBC will have features that the binary will not use (IF EGLIBC did in fact disable some features), but that's usual anyway: it's rare for a binary to use every GLIBC interface.
I was following instructions here and here to build a toolchain which would work on Windows and compile applications for Linux and different hardware platforms. At first I tried to create cross-compiler for i686-linux to test it on a generic Debian 8 system.
Binutils and GCC compiled fine, but I got stuck at Glibc. It told me:
*** The GNU C library is currently not available for this platform.
I see that Sysprogs toolchains are using Newlib instead of Glibc but I haven't found any explanations except that Newlib is a good choice for embedded devices.
Does it mean that Newlib is actually the only choice for Windows -> Linux and that there is no way to compile software which depends on Glibc? Maybe there are "cheats", like copying pre-built Glibc from the target platform or some other workaround?
In theory, I don't even need Glibc built on Windows, I need just some "Glibc compatible stub" built for the target architecture to link (only dynamically, of course) against while compiling for the target platform and OS. Or am I totally wrong here and GCC cannot link to a different C library than GCC itself was linked to?
Or should I forget it and accept the fact that it is impossible (and, most probably, never will be possible) to achieve full Glibc and Linux kernel compatible C/C++ cross-compiling from Windows to GNU/Linux?
I will accept the answer which explains how GCC and Glibc are related and whether it is possible or not to link against Glibc different from C library used when GCC itself was built, and provide some insight about why it is / is not possible.
my guess is you're using --target when building glibc when you really need to use --host (which is different from how newlib is configured -- best to not ask why).
that said, the glibc build system requires a case-sensitive file system as it creates files like foo.oS and foo.os which are very different things. on a system like Windows, that means the build will be corrupted and fail since foo.oS and foo.os refer to the same file. there are patches out there to hack around this, but really you'd be better off booting a VM and doing the toolchain build inside of that.
NB: i'm not saying you need the VM to do all your development. you just need the VM to build the cross-compiler which you'd then run under Windows. this would be a canadian cross build.
rather than do all this yourself by hand, please check out crosstool-ng. it handles/patches/fixes a lot of common errors people make when trying to create cross-compilers.
Not exactly programming/code related, but related to Linaro compiler utilities toolchain.
I am trying to find a Linaro toolchain for Windows platform for armv7-a architecture, but which is compiled/configured with a soft floating point abi i.e. --with-float=soft
I have searched here but there is none which i am looking for.
If there isn't any I would try to build one. Towards that, would appreciate pointers about how to build a linaro toolchain.
What are steps involved in building the linaro toolchain either on Ubuntu Linux or on a Windows under cygwin?
If you go further back (to 12.04) you can find the older, non-hf versions. The instructions to build them are in the README.txt. The README.txt, source and crosstool package are in the same place. You use an Ubuntu machine to build the Windows-hosted tools.