You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

145 lines
5.7 KiB

Build Linux binary in an older docker container (#268) Currently our Linux binaries aren't quite as portable as they otherwise could be. There's two primary reasons for this, and one of them is that the binary is produced in a relatively recent Linux distribution (Ubuntu 16.04) which means it has a relatively recent requirement in terms of glibc versions. On OSX/Windows we can set some flags to rely on older libc implementations, but on Linux we have to actually build against an older version. This commit switches the container for the build to CentOS 6 instead of the default Ubuntu 16.04. The main trick here is also finding a C++11-capable compiler to compile wabt. Turns out though there's a helpful tutorial for this at https://edwards.sdsu.edu/research/c11-on-centos-6/ and it was as easy as installing a few packages. The second portability concern of our Linux binaries is that they link dynamically to `libstdc++.so` which isn't always installed on target systems, or even if it is it may be too old or have a different ABI. This is solved by statically linking to `libstdc++.a` in the build on Azure by doing a bit of trickery with libraries and what's available. After these results the glibc requirements drops from 2.18 (released in 2013) to 2.6 (released in 2007) and avoids the need for users to have libstdc++.so installed. We may eventually want to investigate fully-static musl binaries, but finding a musl compiler for C++ is something I'm not that good at, so I figure this is probably good enough for now.
5 years ago
steps:
- checkout: self
submodules: true
- template: azure-install-rust.yml
- bash: echo "##vso[task.setvariable variable=RUSTC_VERSION;]`rustc --version`"
displayName: Set rustc version string for caching
# - bash: |
# set -e
# curl -Lfo sccache.tar.gz https://github.com/mozilla/sccache/releases/download/0.2.9/sccache-0.2.9-x86_64-apple-darwin.tar.gz
# tar -xzf sccache.tar.gz
# cp sccache-*/sccache /usr/local/bin/
# displayName: Install sccache (OSX)
# condition: and(succeeded(), eq(variables['Agent.OS'], 'Darwin'))
# - bash: |
# set -e
# curl -Lfo sccache.tar.gz https://github.com/mozilla/sccache/releases/download/0.2.9/sccache-0.2.9-x86_64-unknown-linux-musl.tar.gz
# tar -xzf sccache.tar.gz
# sudo cp sccache-*/sccache /usr/local/bin/
# displayName: Install sccache (Linux)
# condition: and(succeeded(), eq(variables['Agent.OS'], 'Linux'))
# - script: |
# curl -Lfo sccache.tar.gz https://github.com/mozilla/sccache/releases/download/0.2.9/sccache-0.2.9-x86_64-pc-windows-msvc.tar.gz
# tar -xzf sccache.tar.gz
# move sccache-* sccache
# echo "##vso[task.prependpath]%CD%\sccache"
# displayName: Install sccache (Windows)
# condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'))
- bash: |
cargo build --release --bin wasmtime --bin wasm2obj
cargo build --release --features wasmtime-api/wasm-c-api --package wasmtime-api
Build Linux binary in an older docker container (#268) Currently our Linux binaries aren't quite as portable as they otherwise could be. There's two primary reasons for this, and one of them is that the binary is produced in a relatively recent Linux distribution (Ubuntu 16.04) which means it has a relatively recent requirement in terms of glibc versions. On OSX/Windows we can set some flags to rely on older libc implementations, but on Linux we have to actually build against an older version. This commit switches the container for the build to CentOS 6 instead of the default Ubuntu 16.04. The main trick here is also finding a C++11-capable compiler to compile wabt. Turns out though there's a helpful tutorial for this at https://edwards.sdsu.edu/research/c11-on-centos-6/ and it was as easy as installing a few packages. The second portability concern of our Linux binaries is that they link dynamically to `libstdc++.so` which isn't always installed on target systems, or even if it is it may be too old or have a different ABI. This is solved by statically linking to `libstdc++.a` in the build on Azure by doing a bit of trickery with libraries and what's available. After these results the glibc requirements drops from 2.18 (released in 2013) to 2.6 (released in 2007) and avoids the need for users to have libstdc++.so installed. We may eventually want to investigate fully-static musl binaries, but finding a musl compiler for C++ is something I'm not that good at, so I figure this is probably good enough for now.
5 years ago
displayName: Cargo build
# Test what we're about to release in release mode itself. This tests
# everything except lightbeam which requires nightly which happens above.
- bash: cargo test --release --all --exclude lightbeam --exclude wasmtime-wasi-c --exclude wasmtime-py --exclude wasmtime-api
Build Linux binary in an older docker container (#268) Currently our Linux binaries aren't quite as portable as they otherwise could be. There's two primary reasons for this, and one of them is that the binary is produced in a relatively recent Linux distribution (Ubuntu 16.04) which means it has a relatively recent requirement in terms of glibc versions. On OSX/Windows we can set some flags to rely on older libc implementations, but on Linux we have to actually build against an older version. This commit switches the container for the build to CentOS 6 instead of the default Ubuntu 16.04. The main trick here is also finding a C++11-capable compiler to compile wabt. Turns out though there's a helpful tutorial for this at https://edwards.sdsu.edu/research/c11-on-centos-6/ and it was as easy as installing a few packages. The second portability concern of our Linux binaries is that they link dynamically to `libstdc++.so` which isn't always installed on target systems, or even if it is it may be too old or have a different ABI. This is solved by statically linking to `libstdc++.a` in the build on Azure by doing a bit of trickery with libraries and what's available. After these results the glibc requirements drops from 2.18 (released in 2013) to 2.6 (released in 2007) and avoids the need for users to have libstdc++.so installed. We may eventually want to investigate fully-static musl binaries, but finding a musl compiler for C++ is something I'm not that good at, so I figure this is probably good enough for now.
5 years ago
displayName: Cargo test
env:
RUST_BACKTRACE: 1
# - script: sccache --show-stats
# displayName: post-compile sccache stats
- bash: |
echo "##vso[task.setvariable variable=tagName;]`echo $BUILD_SOURCEBRANCH | sed -e 's|refs/tags/||'`"
displayName: Set tag name
condition: startsWith(variables['Build.SourceBranch'], 'refs/tags/')
- bash: |
echo "##vso[task.setvariable variable=tagName;]dev"
displayName: Set tag name to "dev"
condition: not(startsWith(variables['Build.SourceBranch'], 'refs/tags/'))
- bash: echo "##vso[task.setvariable variable=basename;]wasmtime-$(tagName)-x86_64-windows"
displayName: Configure basename var
condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'))
- bash: echo "##vso[task.setvariable variable=basename;]wasmtime-$(tagName)-x86_64-macos"
Build Linux binary in an older docker container (#268) Currently our Linux binaries aren't quite as portable as they otherwise could be. There's two primary reasons for this, and one of them is that the binary is produced in a relatively recent Linux distribution (Ubuntu 16.04) which means it has a relatively recent requirement in terms of glibc versions. On OSX/Windows we can set some flags to rely on older libc implementations, but on Linux we have to actually build against an older version. This commit switches the container for the build to CentOS 6 instead of the default Ubuntu 16.04. The main trick here is also finding a C++11-capable compiler to compile wabt. Turns out though there's a helpful tutorial for this at https://edwards.sdsu.edu/research/c11-on-centos-6/ and it was as easy as installing a few packages. The second portability concern of our Linux binaries is that they link dynamically to `libstdc++.so` which isn't always installed on target systems, or even if it is it may be too old or have a different ABI. This is solved by statically linking to `libstdc++.a` in the build on Azure by doing a bit of trickery with libraries and what's available. After these results the glibc requirements drops from 2.18 (released in 2013) to 2.6 (released in 2007) and avoids the need for users to have libstdc++.so installed. We may eventually want to investigate fully-static musl binaries, but finding a musl compiler for C++ is something I'm not that good at, so I figure this is probably good enough for now.
5 years ago
displayName: Configure basename var
condition: and(succeeded(), eq(variables['Agent.OS'], 'Darwin'))
- bash: echo "##vso[task.setvariable variable=basename;]wasmtime-$(tagName)-x86_64-linux"
displayName: Configure basename var
condition: and(succeeded(), eq( variables['Agent.OS'], 'Linux' ))
- bash: |
set -e
mkdir -p $BUILD_BINARIESDIRECTORY/$BASENAME
if [ "$AGENT_OS" = "Windows_NT" ]; then
ext=.exe
fi
cp LICENSE README.md CACHE_CONFIGURATION.md target/release/{wasmtime,wasm2obj}$ext $BUILD_BINARIESDIRECTORY/$BASENAME
Build Linux binary in an older docker container (#268) Currently our Linux binaries aren't quite as portable as they otherwise could be. There's two primary reasons for this, and one of them is that the binary is produced in a relatively recent Linux distribution (Ubuntu 16.04) which means it has a relatively recent requirement in terms of glibc versions. On OSX/Windows we can set some flags to rely on older libc implementations, but on Linux we have to actually build against an older version. This commit switches the container for the build to CentOS 6 instead of the default Ubuntu 16.04. The main trick here is also finding a C++11-capable compiler to compile wabt. Turns out though there's a helpful tutorial for this at https://edwards.sdsu.edu/research/c11-on-centos-6/ and it was as easy as installing a few packages. The second portability concern of our Linux binaries is that they link dynamically to `libstdc++.so` which isn't always installed on target systems, or even if it is it may be too old or have a different ABI. This is solved by statically linking to `libstdc++.a` in the build on Azure by doing a bit of trickery with libraries and what's available. After these results the glibc requirements drops from 2.18 (released in 2013) to 2.6 (released in 2007) and avoids the need for users to have libstdc++.so installed. We may eventually want to investigate fully-static musl binaries, but finding a musl compiler for C++ is something I'm not that good at, so I figure this is probably good enough for now.
5 years ago
displayName: Copy binaries
- bash: |
set -e
API_BASENAME=${BASENAME}-api
if [ "$AGENT_OS" = "Windows_NT" ]; then
shared_ext=.dll
lib_ext=.lib
elif [ "$AGENT_OS" = "Darwin" ]; then
shared_ext=.dylib
lib_ext=.a
lib_prefix=lib
else
shared_ext=.so
lib_ext=.a
lib_prefix=lib
fi
mkdir -p $BUILD_BINARIESDIRECTORY/$API_BASENAME
cp wasmtime-api/README.md wasmtime-api/LICENSE $BUILD_BINARIESDIRECTORY/$API_BASENAME
mkdir -p $BUILD_BINARIESDIRECTORY/$API_BASENAME/include
cp wasmtime-api/c-examples/wasm-c-api/include/wasm.h $BUILD_BINARIESDIRECTORY/$API_BASENAME/include
mkdir -p $BUILD_BINARIESDIRECTORY/$API_BASENAME/lib
cp target/release/${lib_prefix}wasmtime_api${shared_ext} target/release/${lib_prefix}wasmtime_api${lib_ext} $BUILD_BINARIESDIRECTORY/$API_BASENAME/lib
displayName: Copy c-api binaries
Build Linux binary in an older docker container (#268) Currently our Linux binaries aren't quite as portable as they otherwise could be. There's two primary reasons for this, and one of them is that the binary is produced in a relatively recent Linux distribution (Ubuntu 16.04) which means it has a relatively recent requirement in terms of glibc versions. On OSX/Windows we can set some flags to rely on older libc implementations, but on Linux we have to actually build against an older version. This commit switches the container for the build to CentOS 6 instead of the default Ubuntu 16.04. The main trick here is also finding a C++11-capable compiler to compile wabt. Turns out though there's a helpful tutorial for this at https://edwards.sdsu.edu/research/c11-on-centos-6/ and it was as easy as installing a few packages. The second portability concern of our Linux binaries is that they link dynamically to `libstdc++.so` which isn't always installed on target systems, or even if it is it may be too old or have a different ABI. This is solved by statically linking to `libstdc++.a` in the build on Azure by doing a bit of trickery with libraries and what's available. After these results the glibc requirements drops from 2.18 (released in 2013) to 2.6 (released in 2007) and avoids the need for users to have libstdc++.so installed. We may eventually want to investigate fully-static musl binaries, but finding a musl compiler for C++ is something I'm not that good at, so I figure this is probably good enough for now.
5 years ago
- bash: |
set -e
export WT_VERSION=`cat Cargo.toml | sed -n 's/^version = "\([^"]*\)".*/\1/p'`
"$WIX/bin/candle" -arch x64 -out target/wasmtime.wixobj installer/msi/wasmtime.wxs
"$WIX/bin/light" -out $BUILD_ARTIFACTSTAGINGDIRECTORY/$(basename).msi target/wasmtime.wixobj -ext WixUtilExtension
rm $BUILD_ARTIFACTSTAGINGDIRECTORY/$(basename).wixpdb
displayName: Create installer (Windows)
condition: eq(variables['Agent.OS'], 'Windows_NT')
- task: ArchiveFiles@2
inputs:
rootFolderOrFile: $(Build.BinariesDirectory)/$(basename)
archiveType: 'zip'
archiveFile: '$(Build.ArtifactStagingDirectory)/$(basename).zip'
displayName: Archive files (Win)
condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'))
- task: ArchiveFiles@2
inputs:
rootFolderOrFile: $(Build.BinariesDirectory)/$(basename)
archiveType: 'tar'
tarCompression: 'xz'
archiveFile: '$(Build.ArtifactStagingDirectory)/$(basename).tar.xz'
displayName: Archive files (Unix)
condition: and(succeeded(), ne(variables['Agent.OS'], 'Windows_NT'))
- task: ArchiveFiles@2
inputs:
rootFolderOrFile: $(Build.BinariesDirectory)/$(basename)-api
archiveType: 'zip'
archiveFile: '$(Build.ArtifactStagingDirectory)/$(basename)-c-api.zip'
displayName: Archive c-api files (Win)
condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'))
- task: ArchiveFiles@2
inputs:
rootFolderOrFile: $(Build.BinariesDirectory)/$(basename)-api
archiveType: 'tar'
tarCompression: 'xz'
archiveFile: '$(Build.ArtifactStagingDirectory)/$(basename)-c-api.tar.xz'
displayName: Archive c-api files (Unix)
condition: and(succeeded(), ne(variables['Agent.OS'], 'Windows_NT'))
Build Linux binary in an older docker container (#268) Currently our Linux binaries aren't quite as portable as they otherwise could be. There's two primary reasons for this, and one of them is that the binary is produced in a relatively recent Linux distribution (Ubuntu 16.04) which means it has a relatively recent requirement in terms of glibc versions. On OSX/Windows we can set some flags to rely on older libc implementations, but on Linux we have to actually build against an older version. This commit switches the container for the build to CentOS 6 instead of the default Ubuntu 16.04. The main trick here is also finding a C++11-capable compiler to compile wabt. Turns out though there's a helpful tutorial for this at https://edwards.sdsu.edu/research/c11-on-centos-6/ and it was as easy as installing a few packages. The second portability concern of our Linux binaries is that they link dynamically to `libstdc++.so` which isn't always installed on target systems, or even if it is it may be too old or have a different ABI. This is solved by statically linking to `libstdc++.a` in the build on Azure by doing a bit of trickery with libraries and what's available. After these results the glibc requirements drops from 2.18 (released in 2013) to 2.6 (released in 2007) and avoids the need for users to have libstdc++.so installed. We may eventually want to investigate fully-static musl binaries, but finding a musl compiler for C++ is something I'm not that good at, so I figure this is probably good enough for now.
5 years ago
- task: PublishPipelineArtifact@1
inputs:
path: $(Build.ArtifactStagingDirectory)/
artifactName: 'bundle-$(Agent.OS)'