Now that caches are distinct (https://github.com/travis-ci/travis-ci/issues/4393),
we can use the Travis minimal image.
The minimal image should take less time to setup and lead to quicker builds.
Also addressed while I'm in here:
- No need to delete the broken google-chrome repo in the minimal image
- Set the hostname to work-around an openjdk bug
- Remove the non-functional apt-cache option
- Remove useless message at completion
- Install jre where the java tests are run
This was doing more harm than good. The original intention was to speed up
builds, since a PR's ccache results will be thrown away anyway.
However, each PR maintains its own cache, so disabling writes means that
subsequent pushes don't benefit from the fresh cache. This is significant when
(for example) many headers are touched in a PR, then the PR is updated. With
this change, the updated PR will take advantage of the cache generated during
the PR's previous build.
149641e Travis: Use Blue Box VMs for IPv6 loopback support (Luke Dashjr)
c01f08d Bugfix: depends/Travis: Use --location (follow redirects) and --fail [on HTTP error response] with curl (Luke Dashjr)
5d1148c Travis: Use curl rather than wget for Mac SDK (Luke Dashjr)
1ecbb3b depends: Use curl for fetching on Linux (Luke Dashjr)
1) created rpc-tests.py
2) deleted rpc-tests.sh
3) travis.yml points to rpc-tests.py
4) Modified Makefile.am
5) Updated README.md
6) Added tests_config.py and deleted tests-config.sh
7) Modified configure.ac with script to set correct path in tests_config.py
For Gitian releases:
- Windows builds remain unchanged. libstdc++ was already linked statically.
- OSX builds remain unchanged. libstdc++ is tied to the SDK and not worth
messing with.
- Linux builds now statically link libstdc++.
For Travis:
- Match the previous behavior by adding --enable-reduce-exports as
necessary.
- Use static libstdc++ for the full Linux build.
This is a long chain of errors, and there are likely other changes that could
be made to cope in other places along that chain.
If depends don't build successfully, don't bother trying again for the sake of
better logging. That's likely to hurt more than help. In this case, qt build
failed, and on the second attempt, it appeared to be successful. However, due
to a bad object from an internal gcc error on the first build, the resulting
lib was unusable. This caused bitcoin-qt to not be built, and tests and
packaging which expected bitcoin-qt to be there failed.
The root cause:
Mingw is especially crashy when using -jX, likely compounded by low-memory
environments. I've seen multiple problems with this combo in Gitian as well.
In this case:
i686-w64-mingw32-g++: internal compiler error: Killed (program cc1plus)
...
make[3]: *** [.obj/release/qdrawhelper.o] Error 4
The workaround:
Bump Travis down to using -j2 by default. Additionaly, enable --with-gui for
the windows builds. This will cause configure to fail if qt is not working
while also testing the config flag.
Other failures which may be worth revisiting separately:
- If a depends package fails, maybe remove the workdir so that it doesn't taint
subsequent runs
- See if there's anything repeatable about the ICE when building qt
