cosmicexplorer
commented
6 years ago Changed everything a lot, now we have build-{clang,binutils,cmake,gcc}.sh which can be invoked with a target platform (osx or linux) and a release version (e.g. ./build-gcc.sh osx 7.3.0). This is partially inspired by @illicitonion's comment above about duplicating whole scripts for different versions, and partially because it would be extremely nice if we could compile everything from our trusty docker container (if we can't, then we have lost nothing whatsoever).
Each new script (and functions within those scripts) echoes some single distinct "product" to stdout upon completion, and tries to work within its own subdirectory whenever possible. This idiom may not be necessary but seemed to be make this type of script easier to write and follow.
The idea with this is that ./populate-native-toolchain.sh can be edited and then invoked to fill out the entire directory structure for these scripts. Like anything with enough shell scripts, one begins to wonder whether another language is necessary -- I don't think we're there yet, but I could be wrong. If you run ./populate-native-toolchain.sh you'll find that it fails (that or I'm being rate-limited by the gcc mirror). I haven't verified that all the combinations work, and will do that ASAP -- just want to know whether this seems like a potentially-useful approach for this PR.
gcc (like clang) is being provided for both OSX and Linux. binutils does not support OSX (and I've tried to change that, believe me), so the linker will stay an unsolved problem for now. The scripts for all 3 of these tools will mkdir -p the appropriate output directories and copy the packaged archive over to
build-support/bin/${tool}/${arch}/${version}/${tool}.tar.gz(and also, all are being provided as tgz archives -- BinaryTool is great!).The packages produced by these scripts have been used to successfully compile and link code in an extremely bare Linux environment. The same level of testing has not been done with OSX, but I have done my best to make as much of the script as cross-platform as possible so the only feature gaps are the ones in the software we're depending on.
Be forewarned that gcc can take literal days to build unless you dial up the parallelism (using
MAKE_JOBS), but that you can't do that on OSX due to race conditions (unclear why, but it has always failed when I've tried).Let me know if there's a ton more work to be done here or if these look alright. Obviously these packages are big, and they are also hard to slim down -- that's not saying it's impossible.
Also, here is my pants PR which consumes these subsystems. Please let me know if there are any challenges to getting either of these PRs merged that I haven't considered. Thanks!
I know the history is all screwy, github stopped letting me upload files > 100MB to this repo (even though I'd successfully uploaded them before e.g. clang?) and I'm not sure why. I can spend some effort making the version history cleaner to merge if necessary, especially for a repo with huge binaries where everything can be slow sometimes.