Compiling GCC for different machine on same Architecture

Question

We are trying to build our code base for CentOS 7 machine with x86_64 architecture on CentOS6 with x86_64.

For that we are trying to build a centos7 Toolchain. All the gcc/ld/ar should be statically linked, so that we are ensuring that it will not uses any native centos6 stuff.

In this process, we are able to generate statically linked GCC/AR/LD. But problem was this GCC not generating a statically linked binaries and fails while checking flags during configure at "checking static
flag -static ". Due to this while running those binaries it refers to native libgcc and fails.

We are using the below command for configure.

../gcc../configure -prefix=/mnt/data0/toolchain-vm-temp2 --build=x86_64-CentOS7-linux-gnu-with sysroot=/mnt/data0/tools/gnutools/toolchain-vm --disable-nls --disable-multilib --enable-languages=c,c++ --disable-sim --enable-symvers=gnu --enable__cxa_atexit --enable-lto --with-gnu-ld --enable-static

Can Anyone provide solution or how to achieve this task.

Comments

Install CentOS 7 in a virtual machine.

Answer 1

It's pretty straightforward to build software for "other" distributions using modern versions of GCC... depending on how many dependencies the software has.

For basic system library requirements for a Red Hat system, for example, you just need to get a copy of the base and "devel" RPMs for each of those libraries from the release you want to target, unpack them into a separate directory, then add the --sysroot flag to your invocation of GCC pointing at that directory.

So for example if you get the glibc, glibc-common, glibc-devel, glibc-headers, libgcc, and kernel-headers packages from RHEL5 then unpack them into a directory like "/home/sysrooots/rhel5" (I use cpio with the --no-absolute-filenames option to unpack the RPM) you'll get stuff like:

 /home/sysroots/rhel5/usr/include/...
 /home/sysroots/rhel5/usr/lib/...
 /home/sysroots/rhel5/lib/...
 etc.

Then run "gcc --sysroot /home/sysroot/rhel5 ..." for both compilation AND linking.

Obviously if your software needs more libraries you'll have to add more RPMs, and the farther up the "stack" you go, away from the base system libraries, the more complex and less portable things become.