Linux packaged build: wrong location?

Development Platform & Builds
, , , ,
1

I’ve tried both “staging” and packaging a release of my test project on Linux.

In both cases, I wind up with the following directory structure:

LinuxNoEditor
--- Engine
------ Binaries
--------- ThirdParty
------------ OpenVR
--------------- <...>.so
------------ PhysX3
--------------- <...>.so
------ Source
--------- ThirdParty
----------- ResonanceAudioApi
--------------- <...>.so
--- MyProject
------ Binaries
--------- Linux
------------ MyProject (binary)

Obviously, this is a problem. When I launch my binary, it’s unable to find the shared libraries required to run. Is this a bug? Or am I just doing it wrong?

Thanks!

2

Your packaged project should be located in MyProject/Saved/StagedBuilds/<PlatformName>

For debugging purposes you should also be able to launch the binary from MyProject/Binaries/<PlatformName> using a cooker server. If this also is not working check with ldd if any shared objects are missing.

3

Right, it’s located at MyProject/Saved/StagedBuilds/LinuxNoEditor when I “launch” a profile, or a combination of MyProject/LinuxNoEditor and MyProject/Releases//LinuxNoEditor (metadata appears to be stored at the latter location) when I “package” a build.

The problem is that in both cases, the Linux binary is being placed down one subtree (MyProject/Binaries/Linux) but the .so libraries the binary is dependent on are being placed down a different subtree (Engine/Binaries/ThirdParty and /Engine/Source/ThirdParty). Thus the binary cannot run because it cannot find the dependencies.

Trying to determine if this placement is a bug or if I’ve got something misconfigured.

4

I’m making progress.

“objdump -p MyProject” reveals that the program has RPATHs set up for each set of external libraries. For example:

${ORIGIN}/…/…/…/Engine/Binaries/ThirdParty/OpenVR/OpenVRv1_0_10/linux64

These entries are set up in LinuxToolChain.cs, around line 600. However, the .cs file does not set up an rpath entry for the PhysX libraries. Somehow that entry is being automatically added.

Unfortunately, when UE4Editor builds the binary as part of the staging or packaging process, the PhysX rpath isn’t quite right:

${ORIGIN}/…/…/…/…/Engine/Binaries/ThirdParty/PhysX3/Linux/x86_64-unknown-linux-gnu

Note the extra “…/”. If I build the binary myself and copy it to the Staged folder, that rpath is correct. If I manually add the PhysX rpath entry to LinuxToolChain.cs, that also fixes the problem.

Still trying to narrow down:

  • what’s generating the automatic entry
  • why automatic entries aren’t added for the other third party libs
  • what the best way is to fix this
5

Ah! The other libraries are delayed-loaded. So I guess because the PhysX libs are not delayed-loaded, the rpath entry is added automatically. So now to figure out why there’s an extra “…/” when building from within the editor.

6

Could you double check that you’re using 4.19 and not 4.18. For 4.19, please make sure that you cloned the repo after this commit - there will be a better, more generic fix in 4.20 timeframe, but it should solve the current issue.

7

Interesting. 4.18 shouldn’t have Apex/PhysX libraries as DSOs though, this change is new to 4.19. Did you merge it over manually?

8

Release branch is still 4.18, so might be you changed braches or something…

9

Glad that you sorted it out! :slight_smile:

10

For the plugins I’m using the rpaths are set via the RuntimeDependencies array in the .build.cs. So I would start looking for this or something similar in the PhysiX.build.cs

11

I am on 4.18, so I definitely don’t have that fix.

That’s exactly the temp fix I tried out! I’ll grab those changes.

I’m still curious why the automatic rpath is correct if I build the binary myself, but incorrect if UAT builds as part of staging. :confused:

Thank you!

12

Oh! Well now that you mention it, I think I synced to the “release” branch, which I thought I saw was synced to the 4.18 branch (at the time, I think 4.19 was up to preview 3). Perhaps I was mistaken.

13

Oh my goodness. It appears when I was trying to figure out how to contribute to Unreal on GitHub, I created a local branch based off the “master” branch, and that’s what I’m working out of. >_<

Sorry for the confusion. I’m about 2 weeks into using git. Still a newb. :smiley: