0

I am using a native code DLL in an ASP.NET Core .NET 6 application. I have compiled both a DLL for windows and a .so for Linux. I invoke it with the DLLImport attribute and the .NET loader is normally able to find the file both on Windows and Linux. The native code DLL is copied into the application output directory alongside the rest of the compiled .NET code.

The application works both on Windows and on a test install on Ubuntu in a VM. However when running on Azure App Service (Linux) I get the error :

Unable to load shared library 'mylib' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libmylib: cannot open shared object file: No such file or directory

The application is deployed via Azure DevOps Pipelines using these publish arguments:

arguments: '--configuration $(BuildConfiguration) -r linux-x64 --self-contained true --output $(Build.ArtifactStagingDirectory)'

Azure DevOps Pipelines is able to run unit tests for the application including those which call the native library.

I used SSL and Bash to inspect the file system in Azure App Service and I can see that libmylib.so is present in the directory alongside the rest of the compiled .NET code.

I tried copying it to /usr/local/lib and it still didn't work.

What do I need to do to call this file successfully in Azure App Service? Could I be getting the error because some other dependency is missing?

timanderson
  • 843
  • 1
  • 10
  • 20
  • Progress - ldd tells me it is missing libgomp.so.1 (an openmp lib I'm guessing). Investigating how to add. – timanderson Oct 03 '22 at 08:05
  • An environmental variable is not defined when you are running the server : LD_DEBUG environment variable – jdweng Oct 03 '22 at 11:47
  • OK, after more research the heart of this problem is that the App Service is running on an old version of Debian (buster) that is running glibc 2.28, and my .so has a dependency that requires glibc 2.29. Microsoft has steps to upgrade to Debian bullseye but I have followed them to the letter and still on buster :-(. I think the easiest solution may be to recompile my .so on an old version of Debian. – timanderson Oct 04 '22 at 07:31
  • To debug set the variable LD_DEBUG, See : https://bnikolic.co.uk/blog/linux-ld-debug.html – jdweng Oct 04 '22 at 09:48

2 Answers2

0

You can log in kudu site, the site url should like:

https://your_sitename.scm.azurewebsites.net/newui

Then click the webssh, then run the command to install.

apt-get install libgomp1

If it not works, you can run the apt-get update and apt-get install g++. For more details, please check the test steps which I have test.

And I also have a workaround:

You can create the webapp with docker container. You just make sure it works well in your local.

enter image description here

Jason Pan
  • 15,263
  • 1
  • 14
  • 29
  • 1
    These steps did not work for me, the problem being that the official Microsoft container image for .NET 6.0 LTS has Debian buster and therefore the version of glibc was too old. The container idea should work and I may well switch to that. – timanderson Oct 05 '22 at 07:18
0

The issue here is that the official .NET 6.0 runtime container mcr.microsoft.com/dotnet/aspnet:6.0 currently runs debian buster and the version of glibc is 2.28 which was too old for one of my dependencies.

The .NET 7.0 runtime container is OK but I haven't tried upgrading yet.

The solution I found was to download debian buster and recompile my shared library. This now works, together with installing libgomp1.

timanderson
  • 843
  • 1
  • 10
  • 20