chore: build linux x86_64 ffi against glibc 2.23 #413
Conversation
content-type differs for amd64/arm64 macos machines relates to pact-foundation/pact-js-core#447
| @@ -15,7 +15,9 @@ cargo_flags=( "$@" ) | |||
|
|
|||
| # Build the x86_64 GNU linux release | |||
| build_x86_64_gnu() { | |||
| cargo build --target x86_64-unknown-linux-gnu "${cargo_flags[@]}" | |||
| install_cross | |||
| cargo clean | |||
There was a problem hiding this comment.
Are we sure the cargo clean is necessary before every build? Ideally, we would want Rust to re-use whatever intermediate steps it can to reduce the build time. And I thought that Rust was typically smart enough to recognise when it can re-use steps across different targets.
There was a problem hiding this comment.
Never mind, I just saw the related comment over in the Pact-JS repo 👍
There was a problem hiding this comment.
yeah that is what i would want too, however building with cross isn’t storing all build files in target/ it also seems to be storing things in target/debug or target/release as well which is where we get the issue regarding missing symbols for glibc.
probably should find out where and fix it upstream as it would allow us to cache deps and not need to worry about the glibc conflicts as they should be completely seperated
There was a problem hiding this comment.
Hey @JP-Ellis
Looks like there is a less destructive solution which will help for caching
Use a custom target directory for each cross-compilation target (--target-dir path/to/x).
Linked issue which describes the problems seen during multiple cross runs for diff archs
use cross 0.2.5 to build
x86_64-unknown-linux-gnucargo clean prior to building
pr to trigger release workflow
fixes pact-foundation/pact-js-core#502