Discovered this as part of #17402 and a conversation with gmaxwell.
You can see here that the platform is indeed BE: https://travis-ci.org/elichai/bitcoin/jobs/616656410#L36
This closes https://github.com/bitcoin/bitcoin/issues/6466
Discovered this as part of #17402 and a conversation with gmaxwell.
You can see here that the platform is indeed BE: https://travis-ci.org/elichai/bitcoin/jobs/616656410#L36
This closes https://github.com/bitcoin/bitcoin/issues/6466
Concept ACK
Hope this works!
autotools is doing it's job good :) https://travis-ci.org/bitcoin/bitcoin/jobs/616670043#L2809
13 | +export RUN_UNIT_TESTS=true 14 | +export RUN_FUNCTIONAL_TESTS=false 15 | +export GOAL="install" 16 | +export BITCOIN_CONFIG="--enable-reduce-exports --with-incompatible-bdb" 17 | + 18 | +lscpu
Could add this to the script where we print free?
Now that I see that it's already printing that it's bigendian as part of the configure I don't mind removing this https://travis-ci.org/bitcoin/bitcoin/jobs/616670043#L2148
0 | @@ -0,0 +1,18 @@ 1 | +#!/usr/bin/env bash 2 | +# 3 | +# Copyright (c) 2019 The Bitcoin Core developers 4 | +# Distributed under the MIT software license, see the accompanying 5 | +# file COPYING or http://www.opensource.org/licenses/mit-license.php. 6 | + 7 | +export LC_ALL=C.UTF-8 8 | + 9 | +export HOST=s390x-unknown-linux-gnu
export HOST=s390x-unknown-linux-gnu
# The host arch is unknown, so we run the tests through qemu.
# If the host is arm and wants to run the tests natively, it can set QEMU_USER_CMD to the empty string.
export QEMU_USER_CMD="${QEMU_USER_CMD:"qemu-s390x"}"
And then add in the travis.yml:
QEMU_USER_CMD="" # Can run the tests natively without qemu
(just like we do for arm)
So should I also add the QEMU packages that we have in the ARM script?
Ah good catch, yes.
5 | +# file COPYING or http://www.opensource.org/licenses/mit-license.php. 6 | + 7 | +export LC_ALL=C.UTF-8 8 | + 9 | +export HOST=s390x-unknown-linux-gnu 10 | +export DOCKER_NAME_TAG=s390x/ubuntu:18.04
Is this needed?
I'll check, in the PowerPC one Docker failed to download the right image for the platform (and instead downloaded amd64)
9 | +export HOST=s390x-unknown-linux-gnu 10 | +export DOCKER_NAME_TAG=s390x/ubuntu:18.04 11 | +export PACKAGES="clang llvm python3-zmq qtbase5-dev qttools5-dev-tools libssl1.0-dev libevent-dev bsdmainutils libboost-system-dev libboost-filesystem-dev libboost-chrono-dev libboost-test-dev libboost-thread-dev libdb5.3++-dev libminiupnpc-dev libzmq3-dev libqrencode-dev" 12 | +export NO_DEPENDS=1 13 | +export RUN_UNIT_TESTS=true 14 | +export RUN_FUNCTIONAL_TESTS=false
Why?
They were timing out in PowerPC, but I didn't try them here, though because this is BE we might want to extend the timeout to make it work(because this is way more interesting then PowerPC)
Didn't know that s390x is be
Thanks. Concept ACK
ACK da1f153e5e260f1744ee1bf4f24ca3a74ffea465
Not sure what's up with appveyor though
Just ignore that
Concept ACK -- very nice.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--174a7506f384e20aa4161008e828411d-->
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
Concept ACK
101 | @@ -102,6 +102,12 @@ jobs: 102 | FILE_ENV="./ci/test/00_setup_env_arm.sh" 103 | QEMU_USER_CMD="" # Can run the tests natively without qemu 104 | 105 | + - stage: test 106 | + name: 'S390x [GOAL: install] [unit tests, functional tests]'
name: 'S390x [GOAL: install] [unit tests, no functional tests]'
Is there a chance of including functional tests, or is it just too slow?