So you see it's okay that for something that affects the base of every system built on gcc: There is no standard way of doing it, and that it is okay to change 50 lines in 20 files in gcc/config to get it work. The people building distributions just have to handle it themselves. How do I verify that the GCC build I do will work and compiles with the right files, instead of peeking into host system files? Well picking an actual cross-target would help, but there's way to diagnose gcc builds and it's not just gdb and strace. Where are these things documented? On Fri, Oct 9, 2015 at 12:36 PM, Bryan Hundven <bryanhundven@xxxxxxxxx> wrote: > Henri, Et al... > > On Thu, Oct 8, 2015 at 6:23 PM, Henri Tuhola <henri.tuhola@xxxxxxxxx> 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
