DevContainer: Unable to load shared library 'pact_ffi' or one of its dependencies wit PactNet.5.0.0-beta.2

[franvivas]

Previous issues
I use last version of PactNet as you recommended

Version information:

• OS: (e.g. MacOS ARM, M2)
• PactNet Version: PactNet.5.0.0-beta.2
• .Net Version: 8.0

Describe the bug
I launch my piece of test on DevContainer, but I get this error "Unable to load shared library 'pact_ffi' or one of its dependencies "

Steps To Reproduce
Repo:
link to a repository which reproduces the issue.

Steps: video with demo

Expected behavior
Pass the test

Log Output

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
[xUnit.net 00:00:00.30]     pact_test.xunit.tests.UnitTest1.Test [FAIL]
  Failed pact_test.xunit.tests.UnitTest1.Test [1 ms]
  Error Message:
   System.DllNotFoundException : Unable to load shared library 'pact_ffi' or one of its dependencies. In order to help diagnose loading problems, consider using a tool like strace. If you're using glibc, consider setting the LD_DEBUG environment variable: 
/usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.5/pact_ffi.so: cannot open shared object file: No such file or directory
/workspaces/pact_ffi/pact-test.xunit.tests/bin/Debug/net8.0/pact_ffi.so: cannot open shared object file: No such file or directory
/usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.5/libpact_ffi.so: cannot open shared object file: No such file or directory
/workspaces/pact_ffi/pact-test.xunit.tests/bin/Debug/net8.0/libpact_ffi.so: cannot open shared object file: No such file or directory
/usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.5/pact_ffi: cannot open shared object file: No such file or directory
/workspaces/pact_ffi/pact-test.xunit.tests/bin/Debug/net8.0/pact_ffi: cannot open shared object file: No such file or directory
/usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.5/libpact_ffi: cannot open shared object file: No such file or directory
/workspaces/pact_ffi/pact-test.xunit.tests/bin/Debug/net8.0/libpact_ffi: cannot open shared object file: No such file or directory

  Stack Trace:
     at PactNet.Interop.NativeInterop.LogToBuffer(LevelFilter levelFilter)
   at PactNet.PactExtensions.InitialiseLogging(PactLogLevel level)
   at PactNet.PactExtensions.WithHttpInteractions(IPactV4 pact, Nullable`1 port, IPAddress host)
   at pact_test.xunit.tests.UnitTest1..ctor() in /workspaces/pact_ffi/pact-test.xunit.tests/UnitTest1.cs:line 13
   at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean wrapExceptions)

Failed!  - Failed:     1, Passed:     0, Skipped:     0, Total:     1, Duration: < 1 ms - pact-test.xunit.tests.dll (net8.0)

[adamrodger]

First thing to try is making sure that solution works outside of a dev container. If it does then the problem must be something within the dev container itself. If it doesn't then you can fix that and retry, then perhaps it works in the dev container also.

If it works locally but not inside the dev container then the next thing to try is shelling into the dev container itself and trying to run things manually. That will include exploring the bin directory to work out where the DLL is and why it's not where the search paths listed in the log output expect it to be.

[YOU54F]

nice repros!

What machine are you running on? I assume macos apple silicon (uname -sm) in your terminal

If macos, .NET containers with pact net, on apple silicon won't work due to 2 reasons

1. RFC: Add Linux (libc)-ARM Runtime Support #498 - no builds are currently provided for pact-net that target linux-aarch64
2. qemu is not supported with .NET containers, and thus a workaround of running amd64 containers on apple silicon, won't work for pact-net

I believe I have a workable solution, which also provides musl support, using the existing packaging mechanisms, with full preference to glibc hosts, to preserve existing client behaviour and should result in a nice OOB experience for pact-net.

We can provide aarch64 binaries, but due to limitations with qemu + .NET we can't test them in CI, without relying on another CI provider (CirrusCI / CircleCI), so we would probably want a lower tier of support.

[adamrodger]

Closed due to inactivity