osx - Why are shared libraries linked with absolute paths on OS X? -
so i'm porting game linux os x , having compiled , linked it, i'm running against problems starting – dynamic linker can't find libs.
here's otool -l
output:
./foo: /usr/lib/libsystem.b.dylib (compatibility version 1.0.0, current version 1197.1.1) @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) /system/library/frameworks/coreservices.framework/versions/a/coreservices (compatibility version 1.0.0, current version 59.0.0) /usr/lib/libglew.1.10.0.dylib (compatibility version 1.10.0, current version 1.10.0) /usr/lib/libtheoradec.1.dylib (compatibility version 3.0.0, current version 3.4.0) /usr/lib/libtheora.0.dylib (compatibility version 4.0.0, current version 4.10.0) /usr/local/lib/libvorbis.0.dylib (compatibility version 5.0.0, current version 5.7.0) /usr/local/lib/libogg.0.dylib (compatibility version 9.0.0, current version 9.2.0) @loader_path/libsteam_api.dylib (compatibility version 1.0.0, current version 1.0.0) /users/macosx/some/path/to/code/openal-soft-1.16.0/build/libopenal.1.dylib (compatibility version 1.0.0, current version 1.16.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
the thing is, of paths plain wrong. instance, neither glew nor ogg/vorbis/theora exist in /usr/…
, , whatever reason path openal soft burnt in absolute 1 built.
still, setting dyld_library_path
correctly, can game start. however, multiple reasons i'd prefer not embed system's absolute paths within binary.
what's going on here? there way forcefulness relative paths (that's @loader_path
thing, presume?) on libraries of choice? there documentation on matter available?
just @trojanfoe suggested – works:
install_name_tool -change <from> <to> <executable>
osx shared-libraries ld dynamic-linking dyld
No comments:
Post a Comment