So I’ve spent the last day trying to figure out why my Mac OS X app wouldn’t use the SDL2, SDL2_mixer and SDL2_image frameworks bundled with it. It turns out the problem is that they have been built with:
I was able to use install_name_tool on my executable to change the paths to that, but when I try to use it on the bundle framework binaries themselves, it exits with this error:
I’m about to give up at this point, but if anybody out there have SDL2, SDL2_mixer and SDL2_image frameworks that are suitable for bundling or are willing to help, I’d very much appreciate it.------------------------
Privateer: Ascii Sector (www.asciisector.net)
So I’ve spent the last day trying to figure out why my Mac OS X app wouldn’t use the SDL2, SDL2_mixer and SDL2_image frameworks bundled with it. It turns out the problem is that they have been built with:
I was able to use install_name_tool on my executable to change the paths to that, but when I try to use it on the bundle framework binaries themselves, it exits with this error:
I’m about to give up at this point, but if anybody out there have SDL2, SDL2_mixer and SDL2_image frameworks that are suitable for bundling or are willing to help, I’d very much appreciate it.
So I’ve spent the last day trying to figure out why my Mac OS X app wouldn’t use the SDL2, SDL2_mixer and SDL2_image frameworks bundled with it. It turns out the problem is that they have been built with:
I was able to use install_name_tool on my executable to change the paths to that, but when I try to use it on the bundle framework binaries themselves, it exits with this error:
I’m about to give up at this point, but if anybody out there have SDL2, SDL2_mixer and SDL2_image frameworks that are suitable for bundling or are willing to help, I’d very much appreciate it.
You can of course override this by setting DYLD_LIBRARY_PATH.
I doubt that’s the solution you want but you might confirm that this works as
a first step.
install_name_tool -change requires the new name be shorter than the old one
(or the original built with padding).On 19/02/2015, at 7:41 AM, Christian Knudsen wrote:
In your Xcode project edit “Runtime Search Paths” option for you binary to
"@executable_path/…/Frameworks". It’s a correct way. Using @executable_path instead of @rpath in dynamic library install names in not
recommended by Apple.On Thu, Feb 19, 2015 at 12:07 AM, john skaller < skaller at users.sourceforge.net> wrote:
On 19/02/2015, at 7:41 AM, Christian Knudsen wrote:
So I’ve spent the last day trying to figure out why my Mac OS X app
wouldn’t use the SDL2, SDL2_mixer and SDL2_image frameworks bundled with
it. It turns out the problem is that they have been built with:
I was able to use install_name_tool on my executable to change the paths
to that, but when I try to use it on the bundle framework binaries
themselves, it exits with this error:
I’m about to give up at this point, but if anybody out there have SDL2,
SDL2_mixer and SDL2_image frameworks that are suitable for bundling or are
willing to help, I’d very much appreciate it.
You can of course override this by setting DYLD_LIBRARY_PATH.
I doubt that’s the solution you want but you might confirm that this works
as
a first step.
install_name_tool -change requires the new name be shorter than the old one
(or the original built with padding).
You can of course override this by setting DYLD_LIBRARY_PATH.
I doubt that’s the solution you want but you might confirm that this works as
a first step.
Hmm… That didn’t work:
macs-Mac:MacOS mac$ export DYLD_LIBRARY_PATH=’/Users/mac/Desktop/Ascii Sector.app/Contents/Frameworks’
macs-Mac:MacOS mac$ ./asciisec
dyld: Library not loaded: @rpath/SDL2.framework/Versions/A/SDL2
Referenced from: /Users/mac/Desktop/Ascii Sector.app/Contents/MacOS/./asciisec
Reason: image not found
Trace/BPT trap
In your Xcode project edit “Runtime Search Paths” option for you binary to “@executable_path/…/Frameworks”.?? It’s a correct way. Using @executable_path instead of @rpath in dynamic library install names in not recommended by Apple.
That’s the very first thing I tried (after finding that very advice in a Google search) and it didn’t change anything.
Though, I’m compiling with Free Pascal through Xcode, so maybe some linking parameters aren’t passed on or something?
This is correct and desired default behavior. @rpath was introduced
way back in 10.5 to supersede @executable_path because the latter has
a lot of limitations, such as referencing frameworks embedded in other
frameworks and the former is more flexible/generic to handle many more
cases (including specifying multiple search paths).
But to complete the @rpath contract, your application must set
"Runtime Search Paths" (LD_RUNPATH_SEARCH_PATHS) in your Xcode project
to @loader_path/…/Frameworks (which will reproduce the same behavior
as when @executable_path/…/Frameworks was used).
-EricOn 2/18/15, Christian Knudsen wrote:
So I’ve spent the last day trying to figure out why my Mac OS X app wouldn’t
use the SDL2, SDL2_mixer and SDL2_image frameworks bundled with it. It turns
out the problem is that they have been built with:
But to complete the @rpath contract, your application must set
"Runtime Search Paths" (LD_RUNPATH_SEARCH_PATHS) in your Xcode project
to @loader_path/…/Frameworks (which will reproduce the same behavior
as when @executable_path/…/Frameworks was used).
I also tried @loader_path and that didn’t work either.
Since all the changes I’m making in Xcode don’t seem to do anything, I’m more and more convinced that Xcode just doesn’t pass on paramters to the Free Pascal compiler, so I’m going to try to set all this stuff manually for the compiler. Hopefully that’ll work.
I don’t know anything about Free Pascal, but keep in mind that I think the @loader_path is part of the linker phase, not the compiler
phase, if that makes a difference to you.
I see this snippet in my Xcode console’s link phase:
-Xlinker -rpath -Xlinker @loader_path/…/Frameworks
-EricOn 2/19/15, Christian Knudsen wrote:
Eric Wing wrote:
But to complete the @rpath contract, your application must set
"Runtime Search Paths" (LD_RUNPATH_SEARCH_PATHS) in your Xcode project
to @loader_path/…/Frameworks (which will reproduce the same behavior
as when @executable_path/…/Frameworks was used).
I also tried @loader_path and that didn’t work either.
Since all the changes I’m making in Xcode don’t seem to do anything, I’m
more and more convinced that Xcode just doesn’t pass on paramters to the
Free Pascal compiler, so I’m going to try to set all this stuff manually for
the compiler. Hopefully that’ll work.
I don’t know anything about Free Pascal, but keep in mind that I think the @loader_path is part of the linker phase, not the compiler
phase, if that makes a difference to you.
Yeah, and I’m pretty sure the whole point of using Free Pascal through Xcode is to make use of Xcode’s linker phase, so this is odd.
Eric Wing wrote:
I see this snippet in my Xcode console’s link phase:
-Xlinker -rpath -Xlinker @loader_path/…/Frameworks
Hmmm. I’m not really seeing anything obvious I’m missing.
Try to build your code by hand?
[i.e. with a shell script?]
My stuff has this with otool -l
Load command 16
cmd LC_LOAD_DYLIB
cmdsize 80
name build/release/host/lib/rtl/libdemux_dynamic.dylib (offset 24)
time stamp 2 Thu Jan 1 10:00:02 1970
current version 0.0.0
compatibility version 0.0.0
Load command 17
cmd LC_LOAD_DYLIB
cmdsize 64
name @rpath/SDL2.framework/Versions/A/SDL2 (offset 24)
time stamp 2 Thu Jan 1 10:00:02 1970
current version 3.1.0
compatibility version 1.0.0
Load command 18
cmd LC_LOAD_DYLIB
cmdsize 88
name /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (offset 24)
time stamp 2 Thu Jan 1 10:00:02 1970
current version 1.0.0
compatibility version 1.0.0
Load command 19
cmd LC_LOAD_DYLIB
cmdsize 80
name @rpath/SDL2_image.framework/Versions/A/SDL2_image (offset 24)
time stamp 2 Thu Jan 1 10:00:02 1970
current version 1.0.0
compatibility version 1.0.0
Load command 20
cmd LC_LOAD_DYLIB
cmdsize 72
name @rpath/SDL2_ttf.framework/Versions/A/SDL2_ttf (offset 24)
time stamp 2 Thu Jan 1 10:00:02 1970
current version 11.2.0
compatibility version 11.0.0
Load command 21
cmd LC_LOAD_DYLIB
cmdsize 56
name /usr/lib/libstdc++.6.dylib (offset 24)
time stamp 2 Thu Jan 1 10:00:02 1970
current version 7.9.0
compatibility version 7.0.0
I use the DYLD_LIBRARY_PATH to override entries like command 16
(which has an absolute pathname that is entirely wrong once the
libraries are installed).
the @rpath SDL stuff comes from -framework on the C++ compiler.On 20/02/2015, at 12:44 AM, Christian Knudsen wrote:
macs-Mac:MacOS mac$ otool -L asciisec
asciisec:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 15.0.0) @rpath/SDL2.framework/Versions/A/SDL2 (compatibility version 1.0.0, current version 3.1.0) @rpath/SDL2_image.framework/Versions/A/SDL2_image (compatibility version 1.0.0, current version 1.0.0) @rpath/SDL2_mixer.framework/Versions/A/SDL2_mixer (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)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.43.0)
Hmmm. I’m not really seeing anything obvious I’m missing.
What does
otool -L
report when you run it on the application binary?
The text i posted was from that. To be specific this application
happens to be represented as a dylib using a stub loader.
Let me try a static link variant … this is the same program
statically linked into an executable:
Load command 10
cmd LC_LOAD_DYLIB
cmdsize 64
name @rpath/SDL2.framework/Versions/A/SDL2 (offset 24)
time stamp 2 Thu Jan 1 10:00:02 1970
current version 3.1.0
compatibility version 1.0.0
Load command 11
cmd LC_LOAD_DYLIB
cmdsize 88
name /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (offset 24)
time stamp 2 Thu Jan 1 10:00:02 1970
current version 1.0.0
compatibility version 1.0.0
Load command 12
cmd LC_LOAD_DYLIB
cmdsize 80
name @rpath/SDL2_image.framework/Versions/A/SDL2_image (offset 24)
time stamp 2 Thu Jan 1 10:00:02 1970
current version 1.0.0
compatibility version 1.0.0
Load command 13
cmd LC_LOAD_DYLIB
cmdsize 72
name @rpath/SDL2_ttf.framework/Versions/A/SDL2_ttf (offset 24)
time stamp 2 Thu Jan 1 10:00:02 1970
current version 11.2.0
compatibility version 11.0.0
Load command 14
cmd LC_LOAD_DYLIB
cmdsize 56
name /usr/lib/libSystem.B.dylib (offset 24)
time stamp 2 Thu Jan 1 10:00:02 1970
current version 125.2.11
compatibility version 1.0.0
Load command 15
cmd LC_LOAD_DYLIB
cmdsize 56
name /usr/lib/libstdc++.6.dylib (offset 24)
time stamp 2 Thu Jan 1 10:00:02 1970
current version 7.9.0
compatibility version 7.0.0
And on the framework?
I’m not generating frameworks or bundles or whatever.
Basically I use the Unix development model,
in fact I used to use “built from source” SDL installed
in the Unix way. I had to change because I cannot
build 2.0.3 from source, so now I’m using SDL2 framework
because that’s how the binary is distributed from libSDL.org.
You’re using Free Pascal, I’m using Felix which generates
C++ which is then compiled into either a shared library or
executable. If it’s a library a stub loader runs it
(all Felix programs use the same stub loader).
The static link variant is just the same code linked
to the stub loader (with some trivial changes like
changing dlsym (“symbol)”) to just symbol.
~/felix>otool -L gui_01_window_01
gui_01_window_01: @rpath/SDL2.framework/Versions/A/SDL2 (compatibility version 1.0.0, current version 3.1.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0) @rpath/SDL2_image.framework/Versions/A/SDL2_image (compatibility version 1.0.0, current version 1.0.0) @rpath/SDL2_ttf.framework/Versions/A/SDL2_ttf (compatibility version 11.0.0, current version 11.2.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
~/felix>otool -L ~/.felix/cache/binary/Users/johnskaller/felix/src/web/tutopt/sdlgui/gui_01_window_01.dylib
/Users/johnskaller/.felix/cache/binary/Users/johnskaller/felix/src/web/tutopt/sdlgui/gui_01_window_01.dylib:
/Users/johnskaller/.felix/cache/binary/Users/johnskaller/felix/src/web/tutopt/sdlgui/gui_01_window_01.dylib (compatibility version 0.0.0, current version 0.0.0)
build/release/host/lib/rtl/libflx_async_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
build/release/host/lib/rtl/libflx_pthread_dynamic.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)
build/release/host/lib/rtl/libflx_exceptions_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
build/release/host/lib/rtl/libflx_gc_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
build/release/host/lib/rtl/libjudy_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
build/release/host/lib/rtl/libflx_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
build/release/host/lib/rtl/libfaio_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
build/release/host/lib/rtl/libdemux_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/SDL2.framework/Versions/A/SDL2 (compatibility version 1.0.0, current version 3.1.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0) @rpath/SDL2_image.framework/Versions/A/SDL2_image (compatibility version 1.0.0, current version 1.0.0) @rpath/SDL2_ttf.framework/Versions/A/SDL2_ttf (compatibility version 11.0.0, current version 11.2.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)On 20/02/2015, at 1:36 AM, Christian Knudsen wrote:
