-
Notifications
You must be signed in to change notification settings - Fork 232
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
Unable to load shared library 'pact_ffi' or one of its dependencies #387
Comments
That suggests the library The error message describes the next course of action - can you please follow those instructions and paste here? Also your OS/Architecture and .NET version would probably help. @adamrodger should we setup an issue template here? |
agreed, I love docusurus's https://github.com/facebook/docusaurus/issues/new/choose it makes it easier than the commented text that takes up all the space when you want to raise an issue, and I find it easier just to get rid of it all and start my own way. That template above once you click on an option, gives you discreet sections/checklists etc. Some could be consistent for routine pact checks, and we could have library specific sections. |
everything is more awkward with alpine @chertby as many required dependencies for simple programs aren't available. I've often found debian stretch images to be a better starting point as by the time you've got thing you need in alpine, you end up with a much bigger image, and have had a huge time sink to boot |
We do have some instructions for alpine on linux with the ruby core https://docs.pact.io/docker#alpine-linux @chertby if you sort it, we would appreciate you updating the documentation or providing steps for others. |
ah, I don't believe Alpine is supported - see #374. As per the issue, we can't test it reliably yet. |
Are there any plans to support Alpine in version 4.0, maybe I can be of some help to you and try to implement it? |
Yes, we'd like to be able to support Alpine, albeit have a read through the issues linked above to see the current challenges. There is a musl build being published, but we don't have a reliable and repeatable process for testing it here. |
Yep, alpine is not currently supported. I tried to add support but there's
no reliable way of musl vs libc in the conditional compilation so I didn't
manage to get it working.
I think there were problems with the FFI also...? I don't think you can
build shared libs with musl or something, so DllImport doesn't work.
…On Wed, 27 Apr 2022, 09:21 Matt Fellows, ***@***.***> wrote:
Yes, we'd like to be able to support Alpine, albeit have a read through
the issues linked above to see the current challenges. There is a musl
build being published, but we don't have a reliable and repeatable process
for testing it here.
—
Reply to this email directly, view it on GitHub
<#387 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAD4FKSLXIHGK3BQNE5H7ETVHD2G7ANCNFSM5UITJAUA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Yeah, Rust wanted to create a static archive for musl. I believe there is a flag that can be used to compile it into a shared lib, so that's worth experimenting with. |
While it is technically possible to create a dynamically linked library for Alpine, it is not advisable to do so. In essence, what you are creating is a shared library with the musl C library statically linked into it. What this means, if you then try to use this library on a different version of Alpine/musl, it can result in corruption of thread state and segmentation violations. Dynamically linked libraries will have to be built for each specific version of Alpine and musl, and I don't see the benefit in maintaining that. If people what this, I would recommend using Debian based docker images which support dynamically linked glibc. |
Got it, makes sense Ron. Our current docker advice will need updating once the v3 is the major player, else we'll end up confusing people. |
Closing as the FFI lib doesn't support Alpine currently (and may never properly) and so PactNet can't either. We can reopen if the FFI situation changes |
Good shout @mefellows and thanks for the sage advice @uglyog I’ll add it to the list, would be worth adding that advice anyway. I’ve always used and recommended debian stretch for a lightweight image that doesn’t involve the associated complications of alpine, for a few mb’s. |
I was able to get Pact3 going on alpine-node:16 🎉 . This approach blows up the image size considerably, but it's useful in my current situation where we use alpine for local testing only, not deployment. I also tried using gcompat, the glibc-muscl compatibility lib without success. You will need to install
|
Hi Reetu, glad to see you got it working. I will just add a reminder that (as per Ron's comments above) it's highly likely you will eventually run into issues on Alpine with that setup. We don't officially support that setup, so please do note that if you do run into issues. |
Noted. We did end up running into weird problems on different environments (fine on Mac M1, failed on Ubuntu) so we're trying a multi-stage docker build with |
If you want to install pact during RUN apk add --no-cache libc6-compat python3 make g++ That's our workaround to build a front-end app. |
## Rationale pact-reference has introduced musl and arm64 based ffi libraries for linux - pact-foundation/pact-reference#416 Tracking Issue - pact-foundation/roadmap#30 ## Issues Resolved fixes pact-foundation#498 fixes pact-foundation#496 fixes pact-foundation#500 fixes pact-foundation#374 fixes pact-foundation#387 ## Backwards Compatibility Linux glibc based hosts take precedence, so if any error occurs during musl detection. I do not anticipate breaking changes for users ## Implementation notes ### .NET notes - Docs - [Uses MSBuild Exec task](https://learn.microsoft.com/en-us/visualstudio/msbuild/exec-task?view=vs-2022) - MSBuild Blog Posts - [Cross-Platform Build Events in .NET Core using MSBuild](https://jeremybytes.blogspot.com/2020/05/cross-platform-build-events-in-net-core.html) - [MSBuild 101: Using the exit code from a command](https://www.creepingcoder.com/2020/06/01/msbuild-101-using-the-exit-code-from-a-command/) - Stack OverFlow - [Set PropertyGroup property to Exec output](https://stackoverflow.com/questions/76583824/set-propertygroup-property-to-exec-output) - .NET runtime musl detection code - https://github.com/dotnet/runtime/blob/a50ba0669353893ca8ade8568b0a7d210b5a425f/src/mono/llvm/llvm-init.proj\#L7 - https://github.com/dotnet/runtime/blob/a50ba0669353893ca8ade8568b0a7d210b5a425f/src/libraries/Common/tests/TestUtilities/System/PlatformDetection.Unix.cs\#L78t ### Conditions for execution musl detection will run if - if linux - if /lib/ld-musl-(x86_64|aarch64).so.1 exists - if ldd bin/sh | grep musl is true (musl lib is loaded, rather than glibc) will continue on error, reverting back to glibc based libaries. ### Supported musl targets should work for multiple musl based distroes if - /lib/ld-musl-(x86_64|aarch64).so.1 exists - ldd is available (available by default in alpine images) Tested on Alpine ARM64 / AMD64. ## Caveats - [.NET does not run under QEMU](https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md#qemu) affecting the ability to test multi-arch from a single system - .NET restore can take a long time when running under containers. - [Workaround](NuGet/Home#13062 (comment)): Set `DOTNET_NUGET_SIGNATURE_VERIFICATION` to `false` ## Compatibility ### Operating System Due to using a shared native library instead of C# for the main Pact logic only certain OSs are supported: | OS | Arch | Support | | ------------ | ----------- | -------------------------------------------------------------------| | Windows | x86 | ❌ No | | Windows | x64 | ✔️ Yes | | Linux (libc) | x86 | ❌ No | | Linux (libc) | x64 | ✔️ Yes | | Linux (musl) | x64 | ✔️ Yes (Tier 2)* | | Linux (libc) | ARM | ✔️ Yes (Tier 3)* | | Linux (musl) | ARM | ✔️ Yes (Tier 3)* | | OSX | x64 | ✔️ Yes | | OSX | ARM (M1/M2) | ✔️ Yes | #### Support - Tier 1 - Established - Full CI/CD support. - Users should not encounter issues - Full reproducible examples running in CI, should be provided by users raising issues - If using musl targets, users should attempt the same test on a libc target (such as debian) - Tier 2 - Recently introduced - Full CI/CD support. - Users may encounter issues - Full reproducible examples running in CI, should be provided by users raising issues - If using musl targets, users should attempt the same test on a libc target (such as debian) - Tier 3 - Recently introduced, No/limited CI/CD support. - Users may encounter issues - Full reproducible examples which can be run by maintainers locally, should be provided by users raising issues
## Rationale pact-reference has introduced musl and arm64 based ffi libraries for linux - pact-foundation/pact-reference#416 Tracking Issue - pact-foundation/roadmap#30 ## Issues Resolved fixes pact-foundation#498 fixes pact-foundation#496 fixes pact-foundation#500 fixes pact-foundation#374 fixes pact-foundation#387 ## Backwards Compatibility Linux glibc based hosts take precedence, so if any error occurs during musl detection. I do not anticipate breaking changes for users ## Implementation notes ### .NET notes - Docs - [Uses MSBuild Exec task](https://learn.microsoft.com/en-us/visualstudio/msbuild/exec-task?view=vs-2022) - MSBuild Blog Posts - [Cross-Platform Build Events in .NET Core using MSBuild](https://jeremybytes.blogspot.com/2020/05/cross-platform-build-events-in-net-core.html) - [MSBuild 101: Using the exit code from a command](https://www.creepingcoder.com/2020/06/01/msbuild-101-using-the-exit-code-from-a-command/) - Stack OverFlow - [Set PropertyGroup property to Exec output](https://stackoverflow.com/questions/76583824/set-propertygroup-property-to-exec-output) - .NET runtime musl detection code - https://github.com/dotnet/runtime/blob/a50ba0669353893ca8ade8568b0a7d210b5a425f/src/mono/llvm/llvm-init.proj\#L7 - https://github.com/dotnet/runtime/blob/a50ba0669353893ca8ade8568b0a7d210b5a425f/src/libraries/Common/tests/TestUtilities/System/PlatformDetection.Unix.cs\#L78t ### Conditions for execution musl detection will run if - if linux - if /lib/ld-musl-(x86_64|aarch64).so.1 exists - if ldd bin/sh | grep musl is true (musl lib is loaded, rather than glibc) will continue on error, reverting back to glibc based libaries. ### Supported musl targets should work for multiple musl based distroes if - /lib/ld-musl-(x86_64|aarch64).so.1 exists - ldd is available (available by default in alpine images) Tested on Alpine ARM64 / AMD64.
Hello.
I have an issue with the current PactNet Beta version (4.0.0-beta.3) in the CI pipeline.
Next, I tried to run the tests in docker with the
mcr.microsoft.com/dotnet/sdk:6.0
image and the tests runed successful.After that, I changed the image to
mcr.microsoft.com/dotnet/sdk:6.0-alpine
and got the following error:What additional information to provide to correct the issue?
The text was updated successfully, but these errors were encountered: