Re: What is the preferred way of building a cross compiler?

[Bryan Hundven <bryanhundven at gmail dot com>]

Henri, Et al...

On Thu, Oct 8, 2015 at 6:23 PM, Henri Tuhola <henri.tuhola@gmail.com> wrote:
> Hi GCC maintainers

[disclaimer: I don't speak as an official gnu/gcc
developer/maintainer, as I am not.]

> I've spent few days trying to figure out how to build a cross compiler
> for my linux distribution. I've found plenty of instructions but only
> the unsatisfying instructions have been worked.
>
> The particular instructions that work are located at the "cross linux
> from scratch" -tutorial:
> http://www.clfs.org/view/CLFS-3.0.0-SYSTEMD/x86_64-64/cross-tools/chapter.html
>
> The problem with these tutorials are that they propose to patch the
> gcc/config -directory and build files to get the library compile
> correct. I wrote my current build scripts based on them and got it to
> work. The problem is that I cannot trust that they keep working on.
>
> I thought for a moment that I had found good instructions at
> http://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/ but
> neither these worked out.
>
> So consider that you're starting out a distribution. What is the
> preferred way of compiling a cross-compiler and then the compiler for
> your platform? The biggest concern seems to be that the paths
>
> Here's a sample of what kind of crazy the clfs scripts consist of,
> after they've patched the gcc/config and replaced every /lib(64)?
> -pattern with /tools/lib

In the LFS example, there is a "bootstrap" process that is different
then a native compiler build of gcc.
In that process, a temporary set of libraries and tools that are
requirements for the final system are put in the /tools and
/cross-tools directories. This next command was and is specific to LFS
(regardless of what LELUX is...):

>     AR=ar LDFLAGS="-Wl,-rpath,/cross-tools/lib" \
>         $GCC_SOURCES/configure --prefix=/cross-tools \
>         --build=${LELUX_HOST} --host=${LELUX_HOST} --target=${LELUX_TARGET} \
>         --with-sysroot=${LELUX} --with-local-prefix=/tools \
>         --with-native-system-header-dir=/tools/include \
>         --disable-nls --disable-shared \
>         --with-mpfr=/cross-tools \
>         --with-gmp=/cross-tools \
>         --with-mpc=/cross-tools \
>         --without-headers --with-newlib --disable-decimal-float
> --disable-libgomp \
>         --disable-libmudflap --disable-libssp --disable-libatomic
> --disable-libitm \
>         --disable-libsanitizer --disable-libquadmath --disable-threads \
>         --disable-multilib --disable-target-zlib --with-system-zlib \
>         --enable-languages=c --enable-checking=release
>     make -j4 all-gcc all-target-libgcc
>     make install-gcc install-target-libgcc
>
> I feel this is important, as there's many other people constructing
> cross compiler tools. Actually I just looked in how gcw0 toolchain has
> been configured:

Where as this one is built in a different environment (probably
exporting CFLAGS, LDFLAGS, etc... outside of the ./configure command):

> Configured with: ./configure --prefix=/opt/gcw0-toolchain/usr
> --sysconfdir=/opt/gcw0-toolchain/etc --enable-shared --enable-static
> --target=mipsel-gcw0-linux-uclibc
> --with-sysroot=/opt/gcw0-toolchain/usr/mipsel-gcw0-linux-uclibc/sysroot
> --disable-__cxa_atexit --with-gnu-ld --disable-libssp
> --disable-multilib --with-gmp=/opt/gcw0-toolchain/usr
> --with-mpfr=/opt/gcw0-toolchain/usr --enable-target-optspace
> --disable-libsanitizer --enable-tls --disable-libmudflap
> --enable-threads --with-mpc=/opt/gcw0-toolchain/usr
> --disable-decimal-float --with-arch=mips32r2 --with-tune=mips32r2
> --with-abi=32 --with-pkgversion='Buildroot 2014.05-gbb847d4'
> --with-bugurl=http://bugs.buildroot.net/ --enable-languages=c,c++
> --with-build-time-tools=/opt/gcw0-toolchain/usr/mipsel-gcw0-linux-uclibc/bin
> --disable-libgomp --enable-lto
>
> Doesn't seem that different.

It is.

AFAIU, there is a build arch [the architecture the compiler is built
on], a host arch [the architecture the compiler runs on], and the
target arch [the architecture the compiler produces binaries for].

<shameless-plug>
You could check out

http://crosstool-ng.org

and

https://github.com/crosstool-ng/crosstool-ng
</shameless-plug>

Again, AFAIU, gcc has the ability to be configured in four different ways:
The Native Compiler: x86_64 (build), x86_64 (host), x86_64 (target)
[not yet in ct-ng] (may be in a different --prefix the the one
provided by the distribution, or maybe the one provided by the
distribution)
Cross-Compiler: x86_64 (build), x86_64 (host), armel (target) [default
in ct-ng] (almost always in a different --prefix, and preferably
relocatable - filesystem wise)
Cross-Native: x86_64 (build), Sparc (host), x86_64 (target) [not yet
in ct-ng] (same as cross-compiler)
Cross-Canadian: x86_64 (build), Sparc (host), aarch64 (target)
[optional in ct-ng] (same as cross-compiler)

GCC is a contributor supported project, much like any other
open-source software project; there is always on-going work to improve
the process of building gcc, as well as adding new features and target
architectures. Help wanted! :)

There are always exceptions to the process of building any variant of
the above examples where changes need to be back-ported from newer
versions of gcc [possibly development versions] (such as say, fixes to
gccgo, different/new or experimental LIBCs, or being able to specify
different library paths for the cross-compiler's architecture specific
libraries/headers - as simple examples) [see also
Yocto-project/OpenEmbedded, rhel, debian, buildroot, crosstool-ng,
openwrt, etc...], or different dependencies on external libraries
(such as gmp, mpfr, isl, libbfd, etc...) or whether it is targeted for
a specific operating system or bare-metal.

Crosstool-NG, Buildroot, LFS, Yocto/OpenEmbedded, rhel, debian,
arch-linux, embedded systems on bare-metal, etc... (at one time Apple)
all mangle with the black-art of building a gcc cross-compiler,
specific for the purpose of the target
architecture-vendor-operatingsystem-libc (tuple) and goal of the
distribution (I.E.: security hardened or compatibility or embedded
niche, etc...). It is not a simple: one command-line to build a
cross-compiler for any architecture kind of thing...
Which is probably the thing that has you confused. As rightfully,
everything should be reproducible, in a consistent way.
Cross-Compilers are just not that way.
Some architectures require different settings and possibly options of
gcc or required libraries to be enabled or disabled to produce the
desired effect.

Cheers,

-Bryan
"Oh no, I've said too much
I haven't said enough" -- REM