Can the RPATH of a Released Linux Executable be Modified: $ORIGIN/netcoredeps

[Linyefeilyft]

When developing and deploying Linux - based applications, dependency management issues often arise. My program needs to call multiple different SDKs to meet diverse functional requirements. Currently, according to the program's architecture and configuration, I need to place the shared object files (SO files) of these SDKs in the $ORIGIN/netcoredeps directory. Here, $ORIGIN is a special variable that points to the directory where the executable itself is located. This setting is a common practice in many Linux program dependency management scenarios, which helps ensure that the program can find the required dependent libraries during runtime.

However, as the project progresses, I'm facing a tough problem. There are SO files with the same names in different SDKs. This situation can lead to serious conflicts, preventing the program from correctly identifying and loading the specific SDK library files it needs, thus affecting the normal operation of the program. To solve this problem, I considered creating separate sub - directories for different SDKs, placing the SO files with the same names but belonging to different SDKs in these sub - directories respectively, in order to achieve effective isolation and management.

But now, a new obstacle has emerged. The released executable cannot call the SO files in these sub - directories. This means that although I have carried out a reasonable directory planning for the files, the program cannot correctly locate the dependent files in these sub - directories at a deeper level during runtime.

Based on this, I would like to ask if it is possible to modify the RPATH value of the executable so that it can correctly identify the SO files in these sub - directories. Or is there any other way to make the sub - directories under netcoredeps effective, ensuring that the program can smoothly call all the required SDK dependent files, thus guaranteeing the stable operation and functional implementation of the program. I'm looking forward to your valuable suggestions and solutions.

[Linyefeilyft]

` internal class DllImportSoDemo
{
[DllImport(@"netcoredeps/sodemo/DllImportSoDemo.so")]
private static extern int add(int x, int y);

 [DllImport(@"netcoredeps/sodemo/DllImportSoDemo.so")]
 private static extern int add1(int x, int y);

 public static int addSO(int x, int y)
 {
     return add(x, y);
 }

 public static int add1SO(int x, int y)
 {
     return add1(x, y);
 }

}`

`#include "../DllImportSoDemo2/ABC.h"
extern "C" {
int add(int a, int b) {

    return ABC::add(a, b);
}

int add1(int a, int b) {

    return a+b;
}

}`

`#include "ABC.h"

int ABC::add(int x, int y)
{
return x+y;
}`

[kekekeks]

NativeLibrary.SetDllImportResolver

[Linyefeilyft]

In the process of software development, when using SDKs, complex dependency issues often arise. Typically, an SDK contains multiple Shared Object (SO) files, and these SO files call each other. Handling these dependencies is prone to problems.

Take my actual project as an example. In the sample, there is a program named DllImportSoDemo, which calls the function ABC::add in another SO file, DllImportSoDemo2. Theoretically, when the program runs to this call, the system should be able to smoothly locate and load the DllImportSoDemo2.so file to execute the function within it. However, in actual operation, a problem occurred, and the system prompts that the DllImportSoDemo2.so file cannot be found.

The occurrence of this situation may be caused by various reasons. First, from the perspective of path settings, the paths for the program to search for dependent SO files during runtime may not be configured correctly, preventing it from locating DllImportSoDemo2.so. For example, the RPATH environment variable or the search paths specified by the program itself may not include the directory where DllImportSoDemo2.so is actually located. Secondly, it could also be a file permission issue. If the user running the program does not have read permission for the DllImportSoDemo2.so file, the system will not be able to load this file. In addition, the version compatibility of dynamic - link libraries cannot be ignored. If the version of DllImportSoDemo2.so does not match the version expected by DllImportSoDemo, it may also lead to errors such as the file not being found or the function not being called properly.

[kekekeks]

.NET Runtime doesn't use rpath for DllImport, it manually calls dlopen. Use NativeLibrary.SetDllImportResolver to override the lookup paths for a particular managed dll.

[kekekeks]

For .so files themselves use chrpath/patchelf

[thevortexcloud]

I will also add if you have access to source code for the native libraries: If possible you should build the native libraries against your system libraries. That way you can avoid doing all this dependency management and everything should work with the same library. Which is how most native Linux programs are built.