OSX: start app with runtime-dependent dylibs - macos

OSX 10.10 Yosemite.
My application depends on Intel IPP.
At compile time it depends on 2 dylibs, but these depend from other dylibs, which are loaded at runtime (and not displayed in otool -L) . When starting my application does not find these libraries.
I do not understand how can I specify for my app (or for the compile time dependent dylibs) a folder to search a path for runtime dylibs.
As far as I can understand, it is necessary to use rpath. But what exactly should be done? How to set runtime search path? Do I need to set a 'rpath' for the executable file or for the dylibs?

I think you will have to use install_name_tool command to add the dylib.
Don't think you can setup a folder that can magically load all the dylib in it. It's against the purpose of code signing and security.

Related

Where does mac osx app require dependent libraries?

I have built a Qt project under mac, but I have problems executing.
Its dependencies have several dylib .
When building the project, the make tool only asks for one of the libs (for example lib.1.0.0,dylib out of lib.1.dylib, lib.1.0.dylib, lib.1.0.0.dylib, lib.1.0.0.0.dylib) - so I know to put it in the .pro file
Some look like links - but it is not always the lib version that looks like a file that is required as a dependency.
But at run time, I don't know which dylib I need, and where to put it.
I tried to place all 4 lib versions in the folder where the app was created - the project folder - but the app didn't execute.
Having done the same in Linux, I had to put the libs in a place set on path - like /usr/local/libs
Where does mac like its libs (shared libs ?) in order to run ?
You should read this document on deploying Qt applications. It will answer your questions. Moving your libraries to a system library path is usually not a good idea.
http://qt-project.org/doc/qt-5/macosx-deployment.html
To sum this up though you need to change the binaries to tell them where the libs are using the otool command.

Qt + CMake for OSX Bundle: Cocoa Platform Plugin

I'm trying to make a bundle for a Qt based application using CMake.
Things seem to be working fine in terms of linkages, but trying to run the app gives me the error:
This application failed to start because it could not find or load the Qt platform plugin "cocoa".
Available platform plugins are: cocoa.
I'm not sure what this means as the two lines of output seem conflicting. The directory platforms/ (which contains libqcocoa.dylib) is in MyApp/Contents/Resources/bin/. Note that the MyApp executable is there as well.
While the platform library was in the correct position relative to the executable, the libqcocoa library was expecting other Qt libraries to which it was linked to be in specific directories. I used a script with install_name_tool -change commands to modify these paths.

Trace dylib loading on Mac OSX

I'm trying to build a Qt-based application on Mac OSX, and something in my application bundle is pulling in a Qt library from /Library rather than from the application bundle.
I've done this successfully in the past, so I know about using install_name_tool to link applications and libraries to the bundle versions of libraries. I've done this, but I must be missing something. I've tried setting DYLD_PRINT_LIBRARIES, but I'm not really sure how this helps: I can see which Qt library is being pulled in from /Library first (QtXml), but I don't know which file in the bundle is pulling in this library.
Is there some trick to tracing back which file is loading a particular library?
Use otool utility to see what libraries are used by your app and where the app expects to find them:
otool -L yourApp.app/Contents/MacOS/yourApp

OSX Xcode - Packaging dependencies libmysqlclient.18.dylib

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.

Xcode, building and dylibs

I've looked at a few related questions and cannot seem to find a solution for myself.
Basically I'm using the libmp3lame.dylib in my Xcode project. The install process for lame produced the .dylib and placed it in usr/local/lib and to get Xcode to build and run the project I changed the Library Search Paths to include the above folder. This works fine.
Now it's come to producing a release version and I want to include the .dylib in the bundle so that the user doesn't have to put up with an install phase or anything similar. I created a copy files phase of the target and this dumps the .dylib into the Frameworks folder in the contents of the bundle. However, running otool on the binary shows that instead of using the .dylib inside the bundle, the compiler has linked it to the usr/local/lib version (even if I delete that version).
Looking at the other results in the otool output I have other frameworks being linked to inside the bundle, just not the .dylib. Looking at the properties for both these frameworks and the .dylib in Xcode I can't see any differences other than file type.
My searching suggests I need to use rpath or similar, but I've no clue where to apply this in Xcode.
My workaround for this issue was to do the following in terminal (I've used Automator to, well, automate this):
install_name_tool -id #executable_path/../Frameworks/libmp3lame.0.0.0.dylib ~/path/to/lib/in/app/libmp3lame.0.0.0.dylib
install_name_tool -change /usr/local/lib/libmp3lame.0.dylib #executable_path/../Frameworks/libmp3lame.0.0.0.dylib ~/path/to/app/Contents/MacOS/AppName
Basically swapping the path to the library from the one in the usr local lib to the one included in the bundle.
My tip is to look at the build output, how does it actually run ld?

Resources