MacToolChain @executable_path linker problem

Development Programming & Scripting C++
, , ,
1

When trying to use a third party dylib, like CoherentUI, on OS X, when trying to get the editor to run, I get the following error:

LogMac:Warning: dlopen failed: dlopen(/PathToProject/Plugins/CoherentUI/Binaries/Mac/UE4Editor-CoherentUIPlugin-Mac-Debug.dylib, 5): Library not loaded: @executable_path/libCoherentUI.dylib
Referenced from: /PathToProject/Plugins/CoherentUI/Binaries/Mac/UE4Editor-CoherentUIPlugin-Mac-Debug.dylib
Reason: image not found
LogModuleManager:Warning: ModuleManager: Unable to load module '/PathToProject/Plugins/CoherentUI/Binaries/Mac/UE4Editor-CoherentUIPlugin-Mac-Debug.dylib' because the file couldn't be loaded by the OS.

When running otool on the Libraries I found the following:

otool -L UE4Editor-CoherentUIPlugin-Mac-Debug.dylib

@rpath/UE4Editor-CoherentUIPlugin-Mac-Debug.dylib (compatibility version 4.7.0, current version 0.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
@executable_path/libCoherentUI.dylib (compatibility version 0.0.0, current version 0.0.0)
/System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport (compatibility version 1.0.0, current version 263.9.0)
/System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication (compatibility version 1.0.0, current version 57020.1.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 21.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 157.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/AVFoundation.framework/Versions/A/AVFoundation (compatibility version 1.0.0, current version 2.0.0)
/System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.8.0)
/System/Library/Frameworks/CoreMedia.framework/Versions/A/CoreMedia (compatibility version 1.0.0, current version 1.0.0)
@rpath/UE4Editor-SlateCore-Mac-Debug.dylib (compatibility version 4.7.0, current version 0.0.0)
@rpath/UE4Editor-Slate-Mac-Debug.dylib (compatibility version 4.7.0, current version 0.0.0)
@rpath/UE4Editor-InputCore-Mac-Debug.dylib (compatibility version 4.7.0, current version 0.0.0)
@rpath/UE4Editor-Core-Mac-Debug.dylib (compatibility version 4.7.0, current version 0.0.0)
@rpath/UE4Editor-CoreUObject-Mac-Debug.dylib (compatibility version 4.7.0, current version 0.0.0)
@rpath/UE4Editor-Engine-Mac-Debug.dylib (compatibility version 4.7.0, current version 0.0.0)
@rpath/UE4Editor-RenderCore-Mac-Debug.dylib (compatibility version 4.7.0, current version 0.0.0)
@rpath/UE4Editor-RHI-Mac-Debug.dylib (compatibility version 4.7.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)

otool -L libCoherentUI.dylib:

@executable_path/libCoherentUI.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.44.0)
/System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)

Reviewing all the libraries used by UE, this is the only instance I can find that uses @executable_path, which might be the reason why it cannot find the dylib. (For example the ThirdParty CEF binary has @rpath instead of @executable_path in its listing)

Looking at the LinkerCommand in the MacToolChain, I find that it runs this command:

xcrun install_name_tool -change libCoherentUI.dylib @rpath/libCoherentUI.dylib "/PathToProject/Plugins/CoherentUI/Binaries/Mac/UE4Editor-CoherentUIPlugin-Mac-Debug.dylib"

Since the library has @executable_path/libCoherentUI.dylib and not just libCoherentUI.dylib, I believe the change isn’t doing what it is supposed to do.

I’m not an expert linker, but I’m curious if this is a problem in the tool chain?

2

I was able to resolve this issue by updating the dylib to use libCoherentUI.dylib instead of @executable_path/libCoherentUI.dylib. Is this just a step that needs to be taken with the dylib or should the build tool be able to handle it?

3

Hi ,

I’d like to let you know that I am currently looking into your issue. I’m glad you found a way to fix it but I’d still like to find out the answer to if this should be handled by the build tool itself or not. I’ll respond here as soon as I find something out.

4

This isn’t the first binary I’ve seen like this. Using the install_name_tool seems to do the trick, but I’m not sure why these binaries would be setup this way packaged.

5

Hi ,

Unfortunately there isn’t a good answer to this at the moment. The reason it is this way is because there isn’t a standard default install name for third party libraries and we simply edit the few that we do use to meet the engine’s standards instead of writing code to handle them all. All I can offer as a workaround would be to rename things as you did.

Have a nice day

6

Good to know. Renaming things isn’t the end of the world :). Thanks for looking into this!