Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gitian: Remove Windows 32 bit build #15939

Merged
merged 2 commits into from May 9, 2019
Merged
Changes from all commits
Commits
File filter...
Filter file types
Jump to…
Jump to file or symbol
Failed to load files and symbols.

Always

Just for now

@@ -97,16 +97,6 @@ jobs:
# This could be removed once the ABI change warning does not show up by default
BITCOIN_CONFIG="--enable-glibc-back-compat --enable-reduce-exports CXXFLAGS=-Wno-psabi"
- stage: test
name: 'Win32 [GOAL: deploy] [no gui or functional tests]'
env: >-
HOST=i686-w64-mingw32
DPKG_ADD_ARCH="i386"
PACKAGES="python3 nsis g++-mingw-w64-i686 wine-binfmt wine32"
RUN_FUNCTIONAL_TESTS=false
GOAL="deploy"
BITCOIN_CONFIG="--enable-reduce-exports --disable-gui-tests"

This comment has been minimized.

Copy link
@luke-jr

luke-jr May 8, 2019

Member

Let's keep the Travis job...

This comment has been minimized.

Copy link
@MarcoFalke

MarcoFalke May 8, 2019

Author Member

Why? I am not aware that this job ever failed and the win64 one didn't. Also, why would we want to waste resources on testing a target that we never ship?
I'd rather have freebsd tests than a win32 one.

This comment has been minimized.

Copy link
@luke-jr

luke-jr May 8, 2019

Member

We ship source code.

This comment has been minimized.

Copy link
@MarcoFalke

MarcoFalke May 8, 2019

Author Member

It is the responsibility of the user to run the tests. You could argue that many users don't run the tests on their target when they download the gitian binaries, but that doesn't apply here. If some users compile on their own, they need to run the tests themselves.

This comment has been minimized.

Copy link
@luke-jr

luke-jr May 8, 2019

Member

Travis doesn't exist to run the tests. It exists to help us developers avoid doing things that will break the tests. (Running the tests is just how we accomplish that.)

This comment has been minimized.

Copy link
@MarcoFalke

MarcoFalke May 8, 2019

Author Member

Either we support win32, test and ship it, or we don't. There is no in-between.

This comment has been minimized.

Copy link
@luke-jr

luke-jr May 8, 2019

Member

I do not agree. We support plenty of things we do not recommend or ship binaries for.

Indeed, the best approach is to compile yourself, which itself falls outside the "ship" scope.

This comment has been minimized.

Copy link
@sdaftuar

sdaftuar May 8, 2019

Member

FWIW I agree with @MarcoFalke here -- seems like not a great use of travis resources to explicitly test a platform that we're no longer interested in continuing to support (who will debug problems if they are found?). On top of that, reducing the load on travis has benefits; I've noticed that the time I wait from updating a PR to having the travis jobs complete has ticked up recently. So I'd rather we not spend those travis cycles on win32 unless it was an important platform to test on for some reason, and the decision to drop it strikes me as a statement that it's not.

This comment has been minimized.

Copy link
@luke-jr

luke-jr May 9, 2019

Member

The decision not to provide binaries isn't necessarily a decision to drop support.

(That being said, I certainly am not interested in providing support, so if nobody else is either...)

- stage: test
name: 'Win64 [GOAL: deploy] [no gui or functional tests]'
env: >-
@@ -29,10 +29,6 @@ DOCKER_EXEC () {
docker exec $DOCKER_ID bash -c "cd $PWD && $*"
}

if [ -n "$DPKG_ADD_ARCH" ]; then
DOCKER_EXEC dpkg --add-architecture "$DPKG_ADD_ARCH"
fi

travis_retry DOCKER_EXEC apt-get update
travis_retry DOCKER_EXEC apt-get install --no-install-recommends --no-upgrade -qq $PACKAGES $DOCKER_PACKAGES

@@ -43,18 +43,6 @@ def test_ELF(self):
self.assertEqual(call_security_check(cc, source, executable, ['-Wl,-znoexecstack','-fstack-protector-all','-Wl,-zrelro','-Wl,-z,now','-pie','-fPIE']),
(0, ''))

def test_32bit_PE(self):
source = 'test1.c'
executable = 'test1.exe'
cc = 'i686-w64-mingw32-gcc'
write_testcode(source)

self.assertEqual(call_security_check(cc, source, executable, ['-Wl,--no-nxcompat','-Wl,--no-dynamicbase']),
(1, executable+': failed DYNAMIC_BASE NX'))
self.assertEqual(call_security_check(cc, source, executable, ['-Wl,--nxcompat','-Wl,--no-dynamicbase']),
(1, executable+': failed DYNAMIC_BASE'))
self.assertEqual(call_security_check(cc, source, executable, ['-Wl,--nxcompat','-Wl,--dynamicbase']),
(0, ''))
def test_64bit_PE(self):
source = 'test1.c'
executable = 'test1.exe'
@@ -98,7 +98,6 @@ def sign():
subprocess.check_call(['bin/gbuild', '-i', '--commit', 'signature='+args.commit, '../bitcoin/contrib/gitian-descriptors/gitian-win-signer.yml'])
subprocess.check_call(['bin/gsign', '-p', args.sign_prog, '--signer', args.signer, '--release', args.version+'-win-signed', '--destination', '../gitian.sigs/', '../bitcoin/contrib/gitian-descriptors/gitian-win-signer.yml'])
subprocess.check_call('mv build/out/bitcoin-*win64-setup.exe ../bitcoin-binaries/'+args.version, shell=True)
subprocess.check_call('mv build/out/bitcoin-*win32-setup.exe ../bitcoin-binaries/'+args.version, shell=True)

if args.macos:
print('\nSigning ' + args.version + ' MacOS')
@@ -31,7 +31,7 @@ script: |
set -e -o pipefail
WRAP_DIR=$HOME/wrapped
HOSTS="i686-w64-mingw32 x86_64-w64-mingw32"
HOSTS="x86_64-w64-mingw32"

This comment has been minimized.

Copy link
@luke-jr

luke-jr May 2, 2019

Member

This looks so bare. Almost makes me want to build a PPC64 Windows binary just for the sake of it. :)

This comment has been minimized.

Copy link
@MarcoFalke

MarcoFalke May 2, 2019

Author Member

Can you install windows on ppc even?

This comment has been minimized.

Copy link
@luke-jr

luke-jr May 2, 2019

Member

NT4 :p

This comment has been minimized.

Copy link
@davehamiltone

davehamiltone May 3, 2019

o dear I have been running bitcoin core on a 32-bit windows system for a few years now. Am I the last one? I'd like to upgrade to 0.18 please. Any chance of having 32-bit windows back, or is it too much bother?

This comment has been minimized.

Copy link
@luke-jr

luke-jr May 6, 2019

Member

Why can't you use the 64-bit build?

This comment has been minimized.

Copy link
@jeffrade

jeffrade May 9, 2019

Contributor

I'll defer to someone who knows more than me, but can a 64-bit build run on a 32-bit machine?

CONFIGFLAGS="--enable-reduce-exports --disable-bench --disable-gui-tests"
FAKETIME_HOST_PROGS="ar ranlib nm windres strip objcopy"
FAKETIME_PROGS="date makensis zip"
@@ -179,6 +179,4 @@ script: |
cp $OUTDIR/bitcoin-*setup-unsigned.exe unsigned/
find . | sort | tar --no-recursion --mode='u+rw,go+r-w,a+X' --owner=0 --group=0 -c -T - | gzip -9n > ${OUTDIR}/${DISTNAME}-win-unsigned.tar.gz
mv ${OUTDIR}/${DISTNAME}-x86_64-*-debug.zip ${OUTDIR}/${DISTNAME}-win64-debug.zip
mv ${OUTDIR}/${DISTNAME}-i686-*-debug.zip ${OUTDIR}/${DISTNAME}-win32-debug.zip
mv ${OUTDIR}/${DISTNAME}-x86_64-*.zip ${OUTDIR}/${DISTNAME}-win64.zip
mv ${OUTDIR}/${DISTNAME}-i686-*.zip ${OUTDIR}/${DISTNAME}-win32.zip
@@ -20,7 +20,6 @@ created. To use it for Bitcoin:

Common `host-platform-triplets` for cross compilation are:

- `i686-w64-mingw32` for Win32
- `x86_64-w64-mingw32` for Win64
- `x86_64-apple-darwin14` for macOS
- `arm-linux-gnueabihf` for Linux ARM 32 bit
@@ -102,30 +102,6 @@ Build using:
CONFIG_SITE=$PWD/depends/x86_64-w64-mingw32/share/config.site ./configure --prefix=/
make
## Building for 32-bit Windows
To build executables for Windows 32-bit, install the following dependencies:
sudo apt install g++-mingw-w64-i686 mingw-w64-i686-dev
For Ubuntu Bionic 18.04 and Windows Subsystem for Linux <sup>[1](#footnote1)</sup>:
sudo update-alternatives --config i686-w64-mingw32-g++ # Set the default mingw32 g++ compiler option to posix.
Note that for WSL the Bitcoin Core source path MUST be somewhere in the default mount file system, for
example /usr/src/bitcoin, AND not under /mnt/d/. If this is not the case the dependency autoconf scripts will fail.
This means you cannot use a directory that located directly on the host Windows file system to perform the build.
Build using:
PATH=$(echo "$PATH" | sed -e 's/:\/mnt.*//g') # strip out problematic Windows %PATH% imported var
cd depends
make HOST=i686-w64-mingw32
cd ..
./autogen.sh # not required when building from tarball
CONFIG_SITE=$PWD/depends/i686-w64-mingw32/share/config.site ./configure --prefix=/
make

## Depends system
For further documentation on the depends system see [README.md](../depends/README.md) in the depends directory.
@@ -221,15 +221,14 @@ Create (and optionally verify) the signed Windows binaries:
./bin/gsign --signer "$SIGNER" --release ${VERSION}-win-signed --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-win-signer.yml
./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-win-signed ../bitcoin/contrib/gitian-descriptors/gitian-win-signer.yml
mv build/out/bitcoin-*win64-setup.exe ../bitcoin-${VERSION}-win64-setup.exe
mv build/out/bitcoin-*win32-setup.exe ../bitcoin-${VERSION}-win32-setup.exe
popd
Commit your signature for the signed macOS/Windows binaries:
pushd gitian.sigs
git add ${VERSION}-osx-signed/"${SIGNER}"
git add ${VERSION}-win-signed/"${SIGNER}"
git commit -a
git commit -m "Add ${SIGNER} ${VERSION} signed binaries signatures"
git push # Assuming you can push to the gitian.sigs tree
popd
@@ -250,8 +249,6 @@ bitcoin-${VERSION}-x86_64-linux-gnu.tar.gz
bitcoin-${VERSION}-osx64.tar.gz
bitcoin-${VERSION}-osx.dmg
bitcoin-${VERSION}.tar.gz
bitcoin-${VERSION}-win32-setup.exe
bitcoin-${VERSION}-win32.zip
bitcoin-${VERSION}-win64-setup.exe
bitcoin-${VERSION}-win64.zip
```
ProTip! Use n and p to navigate between commits in a pull request.
You can’t perform that action at this time.