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

chore: build linux x86_64 ffi against glibc 2.23 #413

Merged
merged 2 commits into from
Apr 29, 2024

Conversation

YOU54F
Copy link
Member

@YOU54F YOU54F commented Apr 29, 2024

use cross 0.2.5 to build x86_64-unknown-linux-gnu

cargo clean prior to building

pr to trigger release workflow

fixes pact-foundation/pact-js-core#502

@YOU54F YOU54F requested review from rholshausen and JP-Ellis April 29, 2024 18:16
@YOU54F YOU54F marked this pull request as ready for review April 29, 2024 18:17
@rholshausen rholshausen merged commit a9e8da3 into master Apr 29, 2024
30 checks passed
@rholshausen rholshausen deleted the glibc/cross_0_2_5_linux_x86_64_2.23 branch April 29, 2024 23:25
@@ -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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Never mind, I just saw the related comment over in the Pact-JS repo 👍

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

cross-rs/cross#724

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[email protected]: Failed to load native module in Linux-x64 platform (redhat ubi8 minimal)
3 participants