runtime: "dotnet test" fails to find .so file in output folder on Ubuntu when LD_LIBRARY_PATH is blank.

From @nguerrera on July 14, 2018 0:14

From @mpp-oliverh on July 11, 2018 21:29

I have a cross-platform project which uses [DllImport] to load a native binary. I have equivalent .dll and .so placed in the application root, set to CopyAlways and they appear in the output folder.

The application runs correctly on both Windows and Linux (Ubuntu) both when published and from the command line with “dotnet run”.

I have a test which calls a method from the loaded library. On Windows the test runs correctly, on a Linux system when LD_LIBRARY_PATH is not set (such as the visualstudio.com hosted Linux build agent) the test fails with a DllNotFoundException.

Setting the LD_LIBRARY_PATH to : (just a colon) causes the tests to pass. I believe an incorrect assumption is made somewhere during the test procedure about LD_LIBRARY_PATH.

Further details below, including further tests.

Many thanks!

Steps to reproduce

Create a project with a [DllImport] method from a library.so file.
Create a test for the method.
Set the library.so file to CopyAlways so it appears in the output folder alongside the normal application dlls.
Use the VSTS hosted linux build agent or host your own linux vsts-agent which has no LD_LIBRARY_PATH by default.
Build the project and run it - the method successfully loads the library.so file from the application folder and runs the imported method properly.
Run “dotnet test” against the project and you get DllNotFoundException.

Expected behavior

The tests run successfully - the .so file is found and loaded by the method under test.

Actual behavior

Error Message: System.DllNotFoundException : Unable to load shared library ‘library.so’ or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: liblibrary: cannot open shared object file: No such file or directory

Additional info

The fact that LD_LIBRARY_PATH is blank is relevant. If LD_LIBRARY_PATH either starts or ends with a : then the test runs correctly.

export LD_LIBRARY_PATH= dotnet test fails with error above

export LD_LIBRARY_PATH=: dotnet test passes

export LD_LIBRARY_PATH=:blah dotnet test passes

export LD_LIBRARY_PATH=blah: dotnet test passes

export LD_LIBRARY_PATH=blah dotnet test fails with error above

export LD_LIBRARY_PATH=path_to_application_output_directory dotnet test passes

Environment data

dotnet --info output:

root@vsts-agent-5c87858b7b-dsbjf:/vsts# dotnet --info .NET Core SDK (reflecting any global.json): Version: 2.1.301 Commit: 59524873d6

Runtime Environment: OS Name: ubuntu OS Version: 16.04 OS Platform: Linux RID: ubuntu.16.04-x64 Base Path: /usr/share/dotnet/sdk/2.1.301/

Host (useful for support): Version: 2.1.1 Commit: 6985b9f684

.NET Core SDKs installed: 2.1.301 [/usr/share/dotnet/sdk]

.NET Core runtimes installed: Microsoft.AspNetCore.All 2.1.1 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All] Microsoft.AspNetCore.App 2.1.1 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 2.1.1 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs: https://aka.ms/dotnet-download

Copied from original issue: dotnet/cli#9649

Copied from original issue: Microsoft/vstest#1690

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 1
Comments: 26 (19 by maintainers)

Most upvoted comments

Hello,

I’d like this issue to be considered for re-opening. The issue is still very present as of 3.1.100 and we have scenarios where loading libraries from the working directory is required and can’t be worked around.

The issue is present on both Linux and macOS (and makes DllImport inconsistent with Windows).

The exact scenario is that we have a closed source native library from a third party vendor that we have to DllImport and must ship in the working directory. This library has another dependency toward a native library from the same vendor that is also in the working directory.

The initial DllImport works but the secondary dependency can’t be found because the LD path is not set to anything.

It would be very much appreciated if the working directory is added to the library discoverability path.

P.S.: it is not a vstest issue, it’s about dotnet run and self-contained apps.

mrhelmut on Dec 10, 2019

Closing as no-repro since I still can’t reproduce this with the given steps.

jkoritzinsky on Jun 7, 2019

I can’t reproduce this failure on .NET Core 2.1.10, 2.2.4, or any 3.0 preview using the most recent SDKs for each on Ubuntu 18.04.

jkoritzinsky on Apr 12, 2019

I’m getting the same issue - only with dotnet run.

.so library file is present next to the compiled executable (actually, I put a copy of the .so file in every directory in the project just for testing purposes)
when LD_LIBRARY_PATH is blank, I get the error (No such file or directory)
if LD_LIBRARY_PATH contains anything, including just :, the program executes successfully.

Again, I’m using dotnet run (not dotnet test). Version is .net core 2.2. I’m happy to provide a gist for with LD_DEBUG=all if that would be helpful.

Arcanaeum on Dec 17, 2018

You can try to run the test with LD_DEBUG=all set. It logs all the details about where runtime dynamic linker looks for shared libraries, what paths it checks and what symbols it maps. If you run your test with and without the LD_LIBRARY_PATH set and share the logs from both e.g. via gist, I can take a look.

janvorli on Nov 23, 2018

@nguerrera thanks for that.

I’m very busy at the moment but I will try and get something going when I can. I don’t have the build environment for the .so but I’ll see what I can do.

Cheers

oliverholliday on Nov 23, 2018