I have just merged https://github.com/JuliaPackaging/BinaryBuilder.jl/pull/355 . This has some implications for those of you building things that depend on specific versions of GCC. In particular, if anything links against
libgfortran, you’re going to need to compile GCC-version-specific tarballs. This is denoted through extra abi tags added to the end of triplets; e.g. we can have things like
x86_64-linux-gnu-gcc7 now. The only compiler ABI stuff that we’re tracking right now is GCC major version (with the possible values
gcc8, which link to libgfortran 3, 4 and 5 respectively), although we have the machinery in place to start differentiating on things such as
cxx11 string ABI choice, which may or may not happen in the future.
As builder repository owners, the main change is that I have added a new audit pass that will check to see if any of your binaries link against
libgfortran. If they do, and the current target is (for instance)
x86_64-linux-gnu (e.g. no “gcc version tag”) then it will print out a big fat warning. The warning will tell you to update your
build_tarballs.jl file to include the line
platforms = expand_gcc_versions(platforms). What this does is just take a single
Platform object that looks like
x86_64-linux-gnu and turn it into
[x86_64-linux-gnu-gcc4, x86_64-linux-gnu-gcc7, x86_64-linux-gnu-gcc8]. In essence, it will force BinaryBuilder to do the full combinatorial explosion of GCC versions for all of your platforms. Here’s an example of how simple a change this is for you.
From the BinaryProvider side,
build.jl for right now the main difference is that
build.jl files are going to use a
choose_download(download_info, platform_key_abi()) function rather than just try to pull a value out of the dict directly (e.g.
download_info[platform_key_abi()]). This is because we need the ability to pull out the entry that corresponds to our GCC version precisely, OR pull out the entry that has no GCC version encoded within it. (e…g. for pure-C dependencies, rather than FORTRAN dependencies). This isn’t a big change, and BB will automatically start generating
build.jl files that conform to this, but it’s a good thing to know. You can see an example of what this looks like in the generated
build.jl for OpenblasBuilder.
This is the critical step we’ve needed in order to have BinaryProvider downloads for things like Arpack.jl that work for from-source builds of Julia and not “just” the official Julia binaries. An incredible amount of work went into this release of BinaryBuilder, and we thank you all for your patience.