Issues Linking and loading third party .so libraries in Linux.

The following problem is in the context of running Unreal on Linux.

We’re attempting to integrate a third party library into unreal that has been precompiled with the correct version of clang.

After going through the example docs (https://dev.epicgames.com/documentation/en\-us/unreal\-engine/integrating\-third\-party\-libraries\-into\-… ), and the template plugin that is generated when making a new plugin for third party libraries, we were only able to successfully get everything linking when we directly copied the plugin, and all the .h files into the unreal plugin directly (in the way presented in the plugin template).

On top of this, when we ran ldd on the plugin’s .so file unreal generated on build, it provided a very weird linker path to our third party .so file (which involved going from the built plugin’s .so dir to the engine dir, back to the location of the third party .so copy’s dir in our project), when we require our linking to be unrelated to the project directory it is compiled in, and either a relative path within the project, or far more ideally a direct link to the external library location stored on the server.

Attempts to run RunUAT.sh to built the plugin independently has had similar results.

We were hoping that you could provide us with a solution for linking to external libraries without having to copy the code and .so files into the plugin itself, and in a way that this plugin can then be built and brought into other unreal projects (on the same engine build) without the original project directory having to exist and be directly accessible by the external user, (or requiring recompiling).

Steps to Reproduce
In Linux,

  • Open unreal project
  • Create a plugin for third party libraries
  • Update $PluginNameLibrary.Build.cs ExampleSoPath to point to lib .so and PublicSystemIncludePaths to point to all relevant .h files
  • Update $PluginName.cpp LibraryPath to point to the same .so file
  • Build.
  • Run ldd on the plugins .so stored in PluginDir/Binary/Linux

At the present time, plugins are expected to be relative to the engine or the project that’s being used, but I believe the Perforce plugin might mirror what you’re trying to do.

Take a look at: PerforceSourceControl.Build.cs and PerforceSourceControl.uplugin in Engine/Plugins/Developer/PerforceSourceControl

and: Perforce.Build.cs in Engine/Source/ThirdParty/Perforce

In this case, the perforce so is a shared object we don’t have the ability to recompile ourselves, and could (in theory) live outside our Engine or Plugins folders. The PerforceSourceControl.uplugin depends on that module, but internally has no connection to its headers or internal .so library.