Unable to load shared library 'pact_ffi' or one of its dependencies

[chertby]

Hello.
I have an issue with the current PactNet Beta version (4.0.0-beta.3) in the CI pipeline.

Error Message:
   System.DllNotFoundException : Unable to load shared library 'pact_ffi' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: Error loading shared library libpact_ffi: No such file or directory

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:

Error Message:
   System.DllNotFoundException : Unable to load shared library 'pact_ffi' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: Error loading shared library libpact_ffi: No such file or directory
  Stack Trace:
     at PactNet.Interop.NativeInterop.LogToBuffer(LevelFilter levelFilter)
   at PactNet.Verifier.InteropVerifierProvider.Initialise()
   at PactNet.Verifier.PactVerifier.InitialiseProvider(String providerName, Uri pactUri)
   at PactNet.Verifier.PactVerifier.ServiceProvider(String providerName, Uri pactUri)

What additional information to provide to correct the issue?

[mefellows]

That suggests the library pact_ffi wasn't installed or does not match your architecture.

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?
@YOU54F we should probably make this consistent (to the degree that makes sense) across the ecosystem.

[YOU54F]

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.

[YOU54F]

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

[YOU54F]

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.

[mefellows]

After that, I changed the image to mcr.microsoft.com/dotnet/sdk:6.0-alpine and got the following error:

ah, I don't believe Alpine is supported - see #374.

As per the issue, we can't test it reliably yet.

[chertby]

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?

[mefellows]

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.

[adamrodger]

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: ***@***.***>

[mefellows]

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.

[uglyog]

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.

[mefellows]

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.

[adamrodger]

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

[YOU54F]

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.

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.

[reetu]

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.

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 ca-certificates, g++, glibc, make, wget and python3 on your alpine image:

RUN apk add --no-cache \
      ca-certificates  \
      g++ \
      make \
      wget

# Install glibc
RUN wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub
RUN wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.28-r0/glibc-2.28-r0.apk
RUN apk add glibc-2.28-r0.apk

# Install python3
ENV PYTHONUNBUFFERED=1
RUN apk add --update --no-cache python3 && ln -sf python3 /usr/bin/python
RUN python3 -m ensurepip
RUN pip3 install --no-cache --upgrade pip setuptools

[mefellows]

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.

[reetu]

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 alpine-node:16 and pact-js-musl:16 instead. I'll let you know how it goes.

[drakulavich]

If you want to install pact during docker build consider adding the following dependencies for Alpine:

RUN apk add --no-cache libc6-compat python3 make g++

That's our workaround to build a front-end app.