Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

Linux packaged build: wrong location?

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:

 --- 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?


Product Version: UE 4.18
more ▼

asked Feb 23 '18 at 04:08 PM in Linux

avatar image

2 2 1 7

avatar image PhilBax Feb 27 '18 at 03:27 PM

I'm making progress.

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


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:


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

avatar image PhilBax Feb 27 '18 at 03:31 PM

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.

avatar image j.mueller RFG Feb 27 '18 at 03:39 PM

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

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

2 answers: sort voted first

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.

more ▼

answered Feb 27 '18 at 03:47 PM

avatar image

2.7k 59 6 88

avatar image PhilBax Feb 27 '18 at 03:51 PM

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. :/

Thank you!

avatar image RCL STAFF Feb 27 '18 at 03:53 PM

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?

avatar image PhilBax Feb 27 '18 at 03:59 PM

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.

avatar image RCL STAFF Feb 27 '18 at 04:01 PM

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

avatar image PhilBax Feb 27 '18 at 04:03 PM

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. :D

avatar image RCL STAFF Feb 27 '18 at 04:08 PM

Glad that you sorted it out! :)

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

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.

more ▼

answered Feb 23 '18 at 05:23 PM

avatar image

j.mueller RFG
304 3 10 10

avatar image PhilBax Feb 23 '18 at 06:57 PM

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.

(comments are locked)
10|2000 characters needed characters left
Viewable by all users
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question