Dual toolchain (revised pull request) #2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Note that recent gcc also pulls in gmp, mpfr and mpc.
For mpfr and mpc we have just opted for the latest release tarballs,
for GMP however we opt for 4.3.2 available on the gcc infrastructure
page, this is a more tested version of GMP and specifically does not
trigger a bug we see in 6.1.0, outlined here:
https://gmplib.org/list-archives/gmp-bugs/2015-December/003848.html
A C++ compiler is required to build itself, at the very least it needs a C++ compiler to pass it's own configure scripts. A host ranlib is required for building GCC, we see this once we get to the cross-compiler build.
GCC 5.3 installs 2 sets of headers, the additional one only contains a bits/ subdirectory with some important details like c++config.h. (the subdirectory is actually named with the host triplet by we create a symlink to that to maintain simplicity in the ccwrap program). This should be harmless for builds of other GCCs which do not include the extra subdirectory.
Required with newer gcc to find limits.h
When setupfor() or build_section() is called, it now supports a second $2 "variant" option. The variant option specifies an alternative script base name for the build recipe and for the patch sources.
When building GCC 5.3 and musl, it is important to set the triplet to something that is -linux-musl* The approach we take here is to assume first that the CROSS_TARGET is setup with something with -gnu in the last portion, and substitute that for -musl in the case we are building with GCC 5.3 and are using the musl libc implementation. This allows the targets to specify a CROSS_TARGET with the 'gnu' word, such as 'armv5l-unknown-linux-gnueabi' and that will automatically translate to the correct triplet 'armv5l-unknown-linux-gnueabi'. Targets which fail to specify the trailing '-gnu' will be problematic but should build fine with the added '-gnu'.
This is very much like the existing binutils package except that it adds --enable-install-libiberty to match what the previous version was doing.
A new gcc build which supports building gcc 5.3.0 against musl.
Adding Gregor Richards' patches to build gcc 5.3 with musl.
Patch source:
https://github.com/GregorR/musl-gcc-patches
The musl-cross-make project provides some patches allowing one
to build a cross linker with musl as it's libc.
https://github.com/richfelker/musl-cross-make
It also provides patches for gcc 5.2, but we've opted for
a more recent patch set for gcc 5.3.
This is an ugly hack but allows us to avoid the whole --with-sysroot approach to building binutils & gcc. We want musl installed in the STAGE_DIR directly for later use with the ccwrap, and gcc wont find it while building unless it's installed under STAGE_DIR/CROSS_TARGET. Probably we can get away with removing STAGE_DIR/CROSS_TARGET entirely after everything is built.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Updated dual-toolchain branch with a fix to gcc-gplv3.sh
We configure gcc with --disable-lto but gcc still produces the binutils wrapper tools gcc-nm, gcc-ar and gcc-ranlib, which require the presence of the lto plugin.
Now we just forcefully remove these wrappers after the build so that unsuspecting packages dont attempt to use these in place of regular binutils for linking and get link time errors.