I am new to Xcode and Mac environment. I am using some dynamic and static libraries like boost, Clucene, etc. I have all the libraries under
MyApp.app/Contents/Resources
I want to set this path as the app's dyld_library_path. I tried editing XXX.plist file like
DYLD_LIBRARY_PATH /mypath/xxx
and setting the environment variable and argument in Xcode Nothing work.
but if I run a shell script like below without double clicking the app in my .dmg it works
#!/bin/bash
clear
cd /Volumes/xxx/myapp.app/Contents/MacOS
export DYLD_LIBRARY_PATH="/Volumes/xxx/myapp.app/Contents/Resources"
./myapp
I am sure this is not the proper way to do this. Is there proper way to set dyld_library_path every time I execute my app?
EDIT:
It also works if u mannualy copy all ur library to clients /usr/lib path... i guess this is also not a proper way to do it.
Setting DYLD_LIBRARY_PATH isn't the best way to solve this problem. It's working around the fact that you've misinformed dyld as to where to find your libraries.
If you run otool -L MyApp.app/Contents/MacOS/MyApp you'll see the paths to the libraries that MyApp wants to load. If any library isn't found at the specified path then dyld will look for the library in the locations specified by DYLD_FALLBACK_LIBRARY_PATH. Setting DYLD_LIBRARY_PATH causes dyld to look for the library in the given locations ahead of the path that the otool command above returned.
The best way to solve this problem is to have your application specify the correct location of the libraries to start with so that setting DYLD_LIBRARY_PATH is not necessary. To do this you need to do the following:
Set the library identifier of each of the libraries that you're bundling inside your application to an #rpath-relative value. You can do this using install_name_tool -id #rpath/libFoo.dylib libFoo.dylib.
Add a Copy Files build phase to copy the libraries in to your application wrapper. MyApp.app/Contents/Frameworks is a typical location. MyApp.app/Contents/Resources should be avoided since binaries aren't resources in the usual sense of the term.
Specify a run path search path when linking your application. This gives the linker a list of paths to use to resolve any #rpath variables that it encounters in any load commands. If you're copying the libraries to MyApp.app/Contents/Frameworks you'll want to specify a run path search path of #loader_path/../Frameworks. You can do this via the LD_RUNPATH_SEARCH_PATHS (Runpath Search Paths) configuration setting in Xcode on your application target.
After doing all this you should be able to re-run the otool command mentioned above and see that the paths to your library are using #rpath-relative paths. You should then be able to run otool -lV MyApp.app/Contents/MacOS/MyApp and see an LC_RPATH load command specified with a value of #loader_path/../Frameworks. Finally, you should be able to run your application and see that it finds the libraries within its Frameworks directory without having DYLD_LIBRARY_PATH set!
Related
In my Xcode project, I have several dynamic libraries that I built with a prefix of "#rpath/lib". I added a "copy files" build phase that includes these dylibs. They are installed to a folder called lib in Frameworks. I also set a Runpath Search path of "#loader_path/../Frameworks" which should be substituted as #rpath when the executable runs. DLYD looks at my binary's runpath which I examine using tool -l command on the binary. This produces:
Load command 47
cmd LC_RPATH
cmdsize 40
path #loader_path/../Frameworks (offset 12)
So I assume that when my binary runs, DLYD will resolve the path the lib folder via the MACH-O binary.
When I run my project, I use Activity Monitor to examine the files the binary has open. I don't see my dynamic libraries being referenced from #loaderpath/../Frameworks/lib where they reside, instead I see them being referenced from /usr/local/lib.
What Xcode settings do I set so my dynamic libraries are properly found? I used the User-Defined build setting 'DYLD_PRINT_BINDINGS' to see what is linking, and I don't see my libraries being linked even though they are eventually linked against the libraries in /usr/local/lib
I have found the script I developed a while back which I used to copy .dylibs into the .app's Framework directory and detect dependent libraries, fixing the library references using install_name_tool. This should be set as a post-build script.
https://github.com/trojanfoe/xcodedevtools/blob/master/copy_dylibs.py
I haven't tested it for a while. The repo also contains the script I now use to bump build numbers, as per this question of mine.
This question already has answers here:
Why doesn't lldb forward my environment variable anymore?
(2 answers)
Closed 4 years ago.
I am working on a project that requires wrapping libc calls particularly file i/o calls like open, read, write, close etc. I have created a shared library (say, wrapper.so) and preload this wrapper.so.
I could successful use this wrapper on Linux by setting the LD_PRELOAD variable. On MAC, I tried setting the DYLD_FORCE_FLAT_NAMESPACE to 1, DYLD_INSERT_LIBRARIES to /path/wrapper.so using 1) .bash_profile, 2)launchctl setenv, 3)LaunchAgent, 4)LaunchDeamon approaches but nothing work.
I tried even setting the DYLD_FORCE_FLAT_NAMESPACE, DYLD_INSERT_LIBRARIES environment variables at application level for specific applications via their Info.plist but this didn't work either.
Note: I could set some random new variable, say MYVAR, with all the above mentioned approaches. So, it is while setting the DYLD_* variables that I have problem setting. Can you please help me set the DYLD_FORCE_FLAT_NAMESPACE, DYLD_INSERT_LIBRARIES variables on MAC.
A shared library (.dylib) on OS X 'knows' where it expects to be installed to and this information is in turn embedded in any executable that links against it so that the executable knows where to find the library at runtime. Weird though it sounds, that's how it works. Apple call it the dylib's 'install name'.
You can see the install name of a dylib by using otool. For example:
$ otool -D wxwidgets.dylib
wxwidgets.dylib:
/Users/dipol/wxPython/dist-darwin/wx-2.8/wxWidgets/lib/wxwidgets.dylib
If there is only one consumer of your dylib then it's probably easiest to tell the dylib to use a relative path, rather than an absolute path, as its install name. You can do this when building the library like so:
gcc -o my_dylib.dylib -install_name #rpath/my_dylib.dylib ...
Then just put the dylib in the same directory as your executable and it should be able to find it. This also works with clang. You can also set the dylib's install name with a utility called install_name_tool, but that's a bit more difficult.
Here are some links you might find useful:
Apple's documentation
https://blogs.oracle.com/dipol/dynamic-libraries,-rpath,-and-mac-os
http://log.zyxar.com/blog/2012/03/10/install-name-on-os-x/
I have a project in Xcode where I set DYLD_FALLBACK_LIBRARY_PATH in the environment variables pane to set where my application should look for libraries to link to (which works well for my purposes)
I am writing a CMakeLists.txt file to generate this project now and I would like to set this property from the script.
I am aware I can do this:
SET(ENV{DYLD_FALLBACK_LIBRARY_PATH} ${DYLD_FALLBACK_LIBRARY_PATH} /path/to/lib)
but when I run I get this error:
'dyld: Library not loaded ... Reason: image not found'
when launching the application. I imagine the statement is not the same.
Does someone know how I can achieve the equivalent of what I have in Xcode from CMakeLists.txt?
I am vaguely aware of the CMake RPATH stuff but I'd rather avoid that if possible.
Thank you for your time!
Cheers!
Tom
I did finally get this working using a slightly different approach. This might not be the perfect solution and work in all cases, but hopefully this will help someone who is having similar problems to me.
The dylib I was trying to link to was libSDL2-2.0.0
If I navigate to where that file is located and run:
otool -L libSDL2-2.0.0.dylib
the top line I get in the output is this:
/usr/local/lib/libSDL2-2.0.0.dylib
if I then navigate to my built executable and run the same command, I see the same thing:
/usr/local/lib/libSDL2-2.0.0.dylib
(my executable links to SDL)
My problem was libSDL2-2.0.0.dylib is not actually located there, it's in my project structure in a libs folder. In order to get the linker to find the lib at runtime, I had to run this command on the dylib
install_name_tool -id "#executable_path/../path/to/lib/<lib_name>" <lib_name>
where #executable_path is the location of the application to run - in my case this was in - build/debug
The project structure:
root/
CMakeLists.txt
project/
lib/
libSDL2-2.0.0.dylib
build/
debug/
my_app
This is an exact mapping for clarity:
install_name_tool -id "#executable_path/../../project/lib/libSDL2-2.0.0.dylib" libSDL2-2.0.0.dylib
If I run otool -L libSDL2-2.0.0.dylib I now see:
#executable_path/../../sdl-test/lib/libSDL2-2.0.0.dylib
in the first line of the output.
If I now build my project again (I'm just building in Xcode), this updates my app with the new relative path to the dylib. You only have to run install_name_tool on the library, you do not also have to run it on your executable, it will be updated when you build it.
If I run otool -L myapp I now see the same relative path to libSDL2-2.0.0.dylib
With that, when launching the app it was able to successfully find the dylib!
My understanding is that this is the way to achieve this on OSX and there isn't a brilliant alternative (other than messing with DYLD_FALLBACK_LIBRARY_PATH which I mentioned in my question)
I hope this has been of some help to someone who had similar difficulties to me!
Resources I found useful:
http://osiris.laya.com/coding/dylib_linking.html
https://www.fmod.org/questions/question/forum-23398/
https://blogs.oracle.com/dipol/entry/dynamic_libraries_rpath_and_mac
UPDATE:
I actually found an even better way to do this using rpaths and thought I'd write up how to do this for future reference:
In my CMakeLists.txt file I added these lines right at the end (after ADD_EXECUTABLE and TARGET_LINK_LIBRARIES:
# set #rpaths for libraries to link against
SET(CMAKE_SKIP_BUILD_RPATH FALSE)
SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
SET(CMAKE_INSTALL_RPATH "${PROJ_LIB_DIR}")
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
(see https://cmake.org/Wiki/CMake_RPATH_handling for more info)
where ${PROJ_LIB_DIR} is where my dylibs are located:
SET(PROJ_LIB_DIR ${CMAKE_CURRENT_LIST_DIR}/lib)
I then ran:
example:
install_name_tool -id "#rpath/<my-dylib>.dylib" <my-dylib>.dylib
actual:
install_name_tool -id "#rpath/libSDL2-2.0.0.dylib" libSDL2-2.0.0.dylib
in the directory where my dylib is located (in my case libSDL2-2.0.0.dylib)
Now when I run cmake and then build my project, my new executable will search for the library in the location I set in the CMakeLists.txt file at runtime. #rpath will be substituted with the path specified in the CMakeLists.txt file and everything just works without explicitly having to set the #executable_path or #loader_path
Does anybody have a good tutorial handy on embedding libclang in a Cocoa app?
In particular I get issues with the rpath at launch saying the dylib couldn't be found.
Error was the lovely
dyld: Library not loaded: #rpath/libclang.dylib
What this error is sadly trying to tell you is that lib clang thinks its #rpath is at the root of your app bundle, but it's not.
I figured this out the hard way just the other day.
It's hard.
You have to do some crazy stuff with libclang.a using Build Phase settings.
In your target's Build Phases, you will need to add a few Run Script Phases.
One will be this:
echo "warning: OTOOL BEGIN1";
pwd;
otool -L ${SRCROOT}/Clangwrap/ClangAndLLVM/lib/libclang.dylib;
echo "Warning: OTOOL END1";
This just does a few things.
First it nicely sandwiches things with a log to see what happened.
The second is it really is just confirming the path to your lib once it's copied. (and yes, you should be copying it into your project to keep things sane.)
otool does this.
SRCROOT is the root of your project, then anything after that is your relative path within you project's folder in Finder to the lib you are going to use.
Again, this just confirms it is where you think it is.
Ok, next step. This is the real doozy.
echo "BEGIN install_name_tool";
install_name_tool -id #executable_path/../Frameworks/libclang.dylib ${SRCROOT}/Clangwrap/ClangAndLLVM/lib/libclang.dylib;
echo "END install_name_tool";
This runs the obscure command line tool install_name_tool and that is used to set the path where the lib thinks it is located within your app's bundle. Without doing this, the lib will think it is in some other path. You will be setting this path to what you intend it to be. In a Mac app, I used the Frameworks folder inside the bundle so I set it as such. The first argument to install_name_tool is the relative path in your app bundle where the lib is going to be. The second argument is where the lib is currently in your project so that install_name_tool can set its executable path.
This literally modifies a bit of the lib so it is loadable. libs must know their own load path.
Note the first step is only optional for your own sanity.
The second step is required, and both should occur before the Compile Sources Build Phase.
Click and drag to move them up.
Now the final step. Add a new Copy Files Phase and this will remain last in your build phases.
Set the destination to the same as the first arg of install_name_tool so you know your relative path is set and that's where you're going to put the lib.
I used Frameworks.
Now add the files to this Build Phase, for iPhone, add libclang.a (I don't think you can use libclang.dylib on iOS)
Note, you saw me use libclang.dylib and that's because I did this on a Mac app project. It should be the same process for just about anything.
this is not an easy or discoverable process, I pieced it together from several blogs and docs.
This may well have been asked before I just couldn't figure out the right term to search.
I'm writing a client-server application to run on an OSX desktop which will talk to a MySQL server on the local network. It seems long-winded to implement a web-services API when basically a bunch of SQL statements will be perfect internally.
I've wrestled with the install procedure for MySQL server on my development machine, ad had to resort to symlinking libmysqlclient.18.dylib into /usr/lib even though i'd put the include path in header search paths.
What I need to know is how do I create a .app file I can send to other machines that will have access to the libmysqlclient.18.dylib file?
I'm used to Windows having installers to do this and a bit new to OSX programming although i've been doing Obj-c for iDevices for 2 years.
Is there a setting which allows the library to be copied into the .app file or do I need to install the mysql connector on each machine - if so, how do I get around the symlink issue, ideally I need it to work from the stock folders.
If this has been answered somewhere else, please point me in the right direction.
At build time the static linker on OS X, ld, writes the shared library identifier of each library that your application links against in to the application binary. At run time the dynamic linker, dyld, attempts to load each shared library from the paths specified in the application binary. You can see this information using otool -L YourApp.app/Contents/MacOS/YourApp.
The fact you needed to symlink libmysqlclient.18.dylib in to /usr/lib suggests that the shared library identifier of libmysqlclient.18.dylib is something like /usr/lib/libmysqlclient.18.dylib. To include the library in your .app bundle in a way that your application will use it rather than looking in /usr/lib you need to:
Change the shared library identifier of libmysqlclient.18.dylib so that dyld will look for the binary relative to your application binary. This is typically done by running install_name_tool -id #executable_path/../Frameworks/libmysqlclient.18.dylib libmysqlclient.18.dylib.
Copy the modified libmysqlclient.18.dylib in to the Frameworks subdirectroy in your application bundle. This is typically done using a Copy Files build phase in your Xcode project.
You should then be able to verify that the install name written in to your application binary is #executable_path/../Frameworks/libmysqlclient.18.dylib rather than /usr/lib/libmysqlclient.18.dylib (using otool -L YourApp.app/Contents/MacOS/YourApp again). If the install name isn't correct then you'll need to ensure that your linker search path is set up to find your modified version of libmysqlclient.18.dylib ahead of any other versions you may have.