I have compiled the python3.6 program on CentOS 6.8 using pyinstaller and tested on a newer version of Linux. It's working as expected. CentOS 6.8 has installed GLIBC 2.12
pyinstaller --onefile --clean --hidden-import sqlite3 --hidden-import pycryptodome my_python.py
However, I'm getting the follwing error when execute the compiled program on Redhat 5.8 as it has installed the GLIBC 2.5
[24522] Error loading Python lib '/tmp/_MEIl16Rvq/libpython3.6m.so.1.0': dlopen: /lib64/libc.so.6: version `GLIBC_2.7' not found (required by /tmp/_MEIl16Rvq/libpython3.6m.so.1.0)
Can you please help me how to compile the python3.6 program on CentOS 6 for Redhat 5.8?
P.S: I cannot update the GLIBC as I'm going to distribute the same program to the many Linux servers.
Answer to this question is listed in pyinstaller's FAQ as first one in GNU/Linux section. Here it is, a bit cut down version with my emphasis.
The executable that PyInstaller builds is not fully static, in that it still depends on the system libc. Under Linux, the ABI of GLIBC is [...] not forward compatible. [...] The supplied binary bootloader should work with older GLIBC. However, the libpython.so and other dynamic libraries still depends on the newer GLIBC. The solution is to compile the Python interpreter with its modules (and also probably bootloader) on the oldest system you have around, so that it gets linked with the oldest version of GLIBC.
Related
Arch Linux is on GLIBC version 2.33 : https://archlinux.org/packages/core/x86_64/glibc/
but Ubuntu 20.04 is on GLIBC 2.31:
$/lib/x86_64-linux-gnu/libc.so.6 --version
GNU C Library (Ubuntu GLIBC 2.31-0ubuntu9.2) stable release version 2.31.
So, when I try to run on Ubuntu 20.04 the executable produced by CX_Freeze on my Arch Linux system, I get:
./Documents/exe.linux-x86_64-3.8/myapp: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./Documents/exe.linux-x86_64-3.8/myappp
./Documents/exe.linux-x86_64-3.8/myapp: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./Documents/exe.linux-x86_64-3.8/myapp)
How to make an executable from Arch linux which works on older Linux system like Ubuntu 20.04 (in term of GLIBC)?
How to make an executable from Arch linux which works on older Linux system like Ubuntu 20.04 (in term of GLIBC)?
Options:
run Ubuntu 20.04 in a virtualized environment and compile it there (ie. docker), or
compile glibc 2.31 from sources and install on archlinux and link your application with it, or
downgrade archlinux to the version with glibc 2.31, or
link statically with glibc or with other C standard library, or
copy compiled glibc libraries and distribute it with your application with a custom configuration and some startup script, or
distribute the whole chroot with archlinux with your application installed (you could use systemd-machine or publish docker image or similar).
TBH just run ubuntu:20.04 in a docker and build your application there. Typically applications are built for each distribution separately anyway.
You need to build a glibc from source and put all the libraries in a folder.
For example, for a Ubuntu 20.04 targeted system (which understands only executables compiled with GLIBC_2.31), put in a GLIBC_LIB folder the 5 produced so files:
ld-2.31.so
ld-linux-x86-64.so.2
libc.so.6
libm.so.6
libpthread.so.0
Then, run CX_Freeze with this:
LD_LIBRARY_PATH=/path/to/GLIBC_LIB python setup.py build
Note: you can't link a specific library file, you need to link a folder where the library is.
I have problem using gcc/g++ after I changed the machine I use,
I installed gcc-4.9.2 in my previous machine, when I moved to the new machine, I copied gcc folder to the new machine.
When I try to use I get this error :
/data/obenchek/gcc-4.9.2/bin/g++: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by /data/obenchek/gcc-4.9.2/bin/g++)
I have already checked this question :
`GLIBC_2.11' not found
If it says right, the version of libc and g++ are not compatible , libc version :
/lib/libc.so.6
GNU C Library stable release version 2.4 (20090904), by Roland McGrath et al.
...
So I should reinstall gcc completely or there is a easier way to resolve this ??
I copied gcc folder to the new machine.
That's your problem: don't copy, install appropriate GCC package instead.
Most UNIX systems, including Linux, guarantee backward compatibility: a binary compiled on an older system continues to run on a newer one.
The reverse is not true: a binary compiled on a newer system often will not run on an older one. This is working "as designed".
In this particular instance, you copied GCC compiled with GLIBC-2.11 or newer to a machine that has GLIBC-2.10 or older. And that doesn't work.
I am trying to install dcmtk 3.6.0 on my linux system gcc version 4.8.2. But i get an error "Resize which is part of ofoset.h is not defined in this scope". Upon reading, i realized that this happens due to mismatch in the versions of the dcmtk and gcc version. But i am not able to find the right one for my complier.
Any help will be deeply appreciated.
gcc version 4.8.2 was not available when DCMTK 3.6.0 was released (see INSTALL file). So, you should download the latest development snapshot of the DCMTK: http://blog.jriesmeier.com/2013/11/how-to-get-the-current-development-version-of-the-dcmtk/
So we have this program which is being compiled in OpenSuse 13.1 with the following configuration:
GCC 4.6-15.1.3
GLIBC 2.14
Libcrypto 1.0
However, it's supposed to run with OpenSuse 10.3 which has the following configuration:
GCC 4.2-24
GLIBC 2.6.1-18
Libcrypto 0.9.8
The only dependency I could find so far was the __isoc99_sscanf which is introduced in GLIBC 2.7. I tried to fix this with writing my own sscanf function and replace it by adding the following line in my source code:
__asm__(".symver __isoc99_sscanf1, __isoc99_sscanf##GLIBC_2.7");
Now I'm left with the libcrypto dependency and it also looks like it's segfaulting on a munmap() (when i strace the program) function when I try to run it in the old OpenSuse environment (could be a GCC thing?)
So basically, I don't really know what the standard procedure is for fixing this kind of backwards compatibility issues. Any idea's on this?
Normally you would simply install the older gcc, glibc, and other libraries on the new OS (usually made available as RPMs for this reason) and make sure you compile only with those. It's an uphill battle to try to fix all the backwards incompatibilities yourself.
To be more thorough you could build in a chroot of the older OS, maybe even package it up into an RPM so the dependencies are automatically checked. Something like the Open Build Service makes this very easy.
I will like to install GHC 7.2.2 on a Redhat x86_64 (RHEL v5) server at work (in my user account. I don't have root access). I downloaded the generic binary for Linux x86_64 from GHC download page. But, when I run configure, it throws glibc version exception for ghc-pwd since the glibc version on Linux is 2.6. The required glibc version is 2.7.
I googled around but didn't find any pre-configured GHC binaries for Redhat 5. I will appreciate pointers on how to work around the glibc version issue if any one has figured it out for RHEL 5 (or any Linux flavor if the workaround is general). Alternatively, if there are zipped binaries for Redhat x86_64 available somewhere, I can download and unzip them, if you point me to them. Otherwise it looks like I am stuck with GHC 6.12 at work.
I built ghc 7.4.1 on stock RHEL 5.3, by starting with a binary build of ghc 6.6 or 6.8 (forget which one) which ran fine on the platform. Then I used that to build ghc 6.12 from source, and then used 6.12 to build 7.4.1 from source. Had to use gcc 4.3 to build 7.4.1, but that's fine as gcc 4.3 is available on RHEL 5.3.
It's not much work, just a fair amount of time for all the builds to complete.
I had a similar problem, so I compile ghc myself. Doing so is non-trivial because you need newer binutils and gcc. But t can be done (all in user-land).
GHC needs a GHC binary available to compile itself. There are precompiled GHC binaries available, but they have been built against newer glibc versions
RHEL 5 has glibc 2.5, so you can use GHC 6.8 and bootstrap from there. Generally GHC can be bootstrapped with $VERSION-2 or newer (the precise version is documented with the source downloads).
You will also need a newer version of gcc. #alex-iliev suggests that gcc 4.3 is sufficient, which is available on RHEL 5. Your alternative is to use Gentoo Prefix to install an up-to-date gcc.
Download and install the precompiled 6.8 in a directory:
wget http://www.haskell.org/ghc/dist/6.8.3/ghc-6.8.3-x86_64-unknown-linux.tar.bz2
bunzip2 ghc-6.8.3-x86_64-unknown-linux.tar.bz2
tar -xf ghc-6.8.3-x86_64-unknown-linux.tar
cd ghc-6.8.3
mkdir ~/ghc_bootstrap_6_8
./configure --prefix=/home/wilfred/ghc_bootstrap_6_8/
make install
Compile 6.12:
wget http://www.haskell.org/ghc/dist/6.12.3/ghc-6.12.3-src.tar.bz2
bunzip2 ghc-6.12.3-src.tar.bz2
tar -xf ghc-6.12.3-src.tar
cd ghc-6.12.3
mkdir ~/ghc_bootstrap_6_12
PATH=/home/wilfred/ghc_bootstrap_6_8/bin:$PATH ./configure --prefix=/home/wilfred/ghc_bootstrap_6_12/
make
make install
Compiling 7.2 and 7.6 is the same process as 6.12. Compiling can take several hours so you may want to look at quick builds (although you'll want a normal build for the final GHC version).
If you do go down the Gentoo Prefix root, just bootstrap your way to GHC 7.2. You can then modify $EPREFIX/usr/portage/eclass/ghc-package.eclass to add the line:
PATH=/home/wilfred/ghc_bootstrap_7_2/bin:$PATH
then simply add ghcbootstrap to your USE flags and:
emerge --nodeps ghc
Its ghc 6.8 to compile 6.12 from source