Closed dvessel closed 1 year ago
I found a work around.
In the build phase script I had to add all these parent paths.
install_name_tool -change ../../../../../mamearcade_headless.dylib @rpath/mamearcade_headless.dylib ${TARGET_BUILD_DIR}/${EXECUTABLE_PATH}
When mamearcade_headless.dylib is built, it gets baked into the dylib and the MAME binary inherits it. It can be inspected with otool.
otool -l mamearcade_headless.dylib
…
Load command 4
cmd LC_ID_DYLIB
cmdsize 72
name ../../../../../mamearcade_headless.dylib (offset 24)
time stamp 1 Wed Dec 31 19:00:01 1969
current version 0.0.0
compatibility version 0.0.0
...
I have no clue why the path is formed that way. Searching for a fix landed me on this page and I figured out the rest. http://clarkkromenaker.com/post/library-dynamic-loading-mac/
EDIT: A better workaround is to use install_name_tool
after compiling the mame dylib with install_name_tool -id mamearcade_headless.dylib mamearcade_headless.dylib
. No need to change the build phase command in Xcode.
Yep, we're aware of this issue and as you can tell use install_name_tool
to resolve. I've noted this in the README https://github.com/OpenEmu/UME-Core/commit/54fd07c8513f626fa957109e7483d1636eec45da
mamearcade_headless.dylib does not get picked up within the core plugin. I had to manually place it in
/usr/local/lib/mamearcade_headless.dylib
for MAME to launch.This is from an ARM build on Monterey with Xcode 13.4.1.