Example: Building gcc-armhf for armhf does not make sense, so this
commit changes arch="all" to arch="aarch64 x86_64". This helps to
simplify the repository scripts (#970).
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.
