This fixes https://github.com/postmarketOS/binary-package-repo/issues/1
GCC generates hardlinks between files `A` and `B` in its `make install` step. The problem is, that `tar` randomly packages `A` as full binary, and links `B` to `A`, or the other way around! I was able to reproduce this issue consistently when re-building `gcc-aarch64` on Travis CI (interestingly, this did not appear for `gcc-armhf`).
The fix is, to delete `B` and create a symlink `B` that points to `A` instead.
libstdc++.a from gcc-armhf was not reproducible on Travis (it was, when built locally!). These .a files are just archives of object files .o, and in this case it was caused by a random order of the .o files in the archive.
This PR patches the package() function of the APKBUILD when running pmbootstrap aportgen gcc-armhf (same for aarch64 of course), to extract all .a files, and repack them to be reproducible (by sorting the files before packing them).
As usually, we can still inherit everything from the upstream gcc aport from Alpine, and apply our changes on top of that.
Travis without the patch:
https://api.travis-ci.org/jobs/260402679/log.txt?deansi=true
> CHALLENGE FAILED for usr/armv6-alpine-linux-muslgnueabihf/lib/libstdc++.a:File 'usr/armv6-alpine-linux-muslgnueabihf/lib/libstdc++.a' is different!
Travis with the patch (I've instructed Travis to run off this branch to test it):
https://api.travis-ci.org/jobs/260806203/log.txt?deansi=true
> Done. Your build exited with 0.
100% tested. Assuming that you don't need to test an obvious change,
because it only changes one line is dangerous. I will learn from this,
sorry for the inconvenience.
`gcc-armhf` compiles fine again with that change, and it is able to
cross-compile packages as it used to.
Oliver Smith