https://pact.io logo
Join Slack
Powered by
<Release - Pact FFI Library 0.4.8> New release pub...
# pact-rust
g
Release - Pact FFI Library 0.4.8 New release published by rholshausen Bugfix Release NOTE: Linux aarch64 (Apple M1) targets are not currently building. If you need to run the Pact FFI on Apple M1 machines, you will have to use the MacOS binary dynlib and not run it via docker. • a3025b1 - chore(pact_ffi): Disable aarch64-unknown-linux-gnu target from release build • c924b9c - chore: Upgrade pact_verifier to 1.0.3 • d592cd8 - chore: Upgrade pact_mock_server to 1.2.3 • 37fa901 - fix(FFI): Stupid Windows #314 • 7fc7bbc - fix(FFI): When appending parts to an existing multipart body, matching rules should still be configured for the new part #314 • bae6b5a - fix(FFI): Allow pactffi_with_multipart_file to append parts to an existing multipart body #314 • 3ec99c4 - chore: Upgrade pact_matching to 1.1.5 • 6df8ce8 - fix(pact_verifier): Fix missing PATCH version in plugin's version (tienvx) • e6484f3 - fix(FFI): Check for the intermediate JSON format when setting the body contents with XML #305 • 66648b4 - fix(FFI): Guard against header names being passed in different case #305 • e4da3e4 - chore: Upgrade pact_models to 1.1.11 • 24ed783 - chore: Upgrade pact-models to 1.1.10 pact-foundation/pact-reference
y
Are these notes correct.
Linux aarch64 (Apple M1)
Linux aarch64 != apple m1 🤷 @uglyog
If you need to run the Pact FFI on Apple M1 machines, you will have to use the MacOS binary dynlib and not run it via docker.
You would use the macos bin dynlib natively. Via docker, I suppose they could fix to use platform linux/amd64. but thats also wider that just affecting macos users, as it affects anyone on linux aarch64 machines - rasp pies for example Happy to take a look at the aarch64 linux building issue
u
Yeah, that be true. Still, it's not building for them too.
Originally there was just the 32-bit architecture, called "ARM". Then in October 2011 the ARMv8-A spec added a new 64-bit execution state called "AArch64", retroactively renaming the old 32-bit architecture "AArch32". Then to add a bit more confusion, in 2017 the company rebranded from being called "ARM" (an acronym for "Advanced RISC Machines") to just "Arm".
Support for AArch64 was added to Linux in 2012. The patchset was initially called "aarch64" but was renamed to "arm64". The LLVM community and Apple started working in parallel to support it in clang in 2012, the LLVM community called it "aarch64" and Apple called it "arm64". Apple open-sourced their changes and the two efforts lived together in LLVM under their different names and were eventually merged in 2014 so LLVM/clang now just calls it "aarch64".
So it is both for ARM and Apple M1 processors
y
Ahhh, so its affecting our aarch64/arm64 builds. the nomenclature is confusing at best xD I got confused when I saw this commit, that just disabled, the linux aarch64 builds, looked through the actions, and couldn't find the failing builds, but didn't look more than 2 pages and everything was green(ish)
more confused, because aarch64/arm64 macos binaries are there https://github.com/pact-foundation/pact-reference/releases/tag/libpact_ffi-v0.4.8
That is really interesting back story about apple and llvm working in parallel for clang support, that makes more sense looking at some of the build scripts across the various languages and tooling
u
It's not Macos binaries, but Linux binaries for that architecture.
For people who want to use Docker on M1 without XF86 simulation. See https://github.com/pact-foundation/pact-reference/issues/160#issuecomment-1203570468
y
ahh gotcha Ron. Cirrus has arm64 native runners, if you want to try building natively without cross
m
sorry guys, I have this thing on my todo where I was to add/update the build script to build one XCFramework for darwin+iOS+mac_catalyst instead of having all these 
.a
bins. Just haven’t gotten to it yet. 🤷
Open in Slack
PreviousNext
Powered by