My app is partitioned into a number of frameworks.
Each framework has its Installation Directory set to #executable_path/../Frameworks, is linked and copied to the main executables Frameworks folder. All is working great.
Now some of the same frameworks are used in a separate screen saver executable.
The frameworks are linked, copied, present in the actual binary -
yet the screensaver module will fail to load with the following error:
Error loading /Users/someuser/Library/Screen Savers/MyScreenSaver.saver/Contents/MacOS/MyScreenSaver: dlopen(/Users/someuser/Library/Screen Savers/MyScreenSaver.saver/Contents/MacOS/MyScreenSaver, 265): Library not loaded: #executable_path/../Frameworks/BusinessBase.framework/Versions/A/BusinessBase
Referenced from: /Users/someuser/Library/Screen Savers/MyScreenSaver.saver/Contents/MacOS/MyScreenSaver
Reason: image not found
Looks like the screen saver (loaded as a plugin) cannot find the frameworks referenced by itself.
I've tried setting the screen savers Framework Search Path to both #loader_path/../Frameworks and #executable_path/../Frameworks.
No luck.
Any ideas what else to try..?
FWIW I've managed to fix this issue with some install_name_tool magic in a post build script:
The key was to change executable_path to loader_path and use the correct relative paths for the binary calling the respective framework.
For a screensaver plugin, #executable_path is the path to the ScreenSaverEngine executable that's loading your screensaver, or to System Preferences if it's running as a preview. It is not the path to your screensaver module! For that, you will need to use #loader_path.
Related
my problem is when I launch the test with OCMockito Xcode inform me that xctest[3096:115464] The bundle “Tests” couldn’t be loaded because it is damaged or missing necessary resources. Try reinstalling the bundle.
and also Library not loaded: #rpath/OCMockito.framework/Versions/A/OCMockito
when I check the path of the OCMockito framework in the search path build setting of the test target, every thing look correct!!!
this my search path settings screen
and this is the OCMockito in the files finder
PS: I used the mockito framework to make tests to static library
I solved the problem the error is that I Used OcMokito instead of OCMockitoIOS :)
We're adding a QuickLook plug-in to our project.
Everything is fine until macOS trying to invoke our plug-in, at which point we're getting the beloved The bundle couldn’t be loaded because it is damaged or missing necessary resources error.
We've checked with otool -L on the plug-in's binary that all dependencies are in place, however as soon as the OS is asking our plug-in for a preview for the file type supported by us we get:
22/04/17 12:03:05,716 quicklookd[55323]:
[QL] Can't load plug-in at file:///Users/myname/Library/Developer/Xcode/DerivedData/The_Project-gpihzjouhxvifqcslmywktktizer/Build/Products/Debug/MyApp.app/Contents/Library/QuickLook/SomeQuickLookPlugIn.qlgenerator/:
The bundle “SomeQuickLookPlugIn” couldn’t be loaded because it is damaged or missing necessary resources.
The one thing we're not quite sure about is the dependency to our internal frameworks.
We've set up the plug-in similar to our main app, i.e. the private framework dependency resolves to:
#executable_path/../Frameworks/MyFW.framework/Versions/A/MyFW (compatibility version 1.0.0, current version 1.0.0)
..which would work OK if #executable_path were either the main app's binary or the plug-in's main binary as we copied the frameworks in both places in the bundle.
Any thoughts?
Ideally we would like the OS to tell us which dependency it failed to resolve -
is there any debug flag that can be set..?
As per https://www.mikeash.com/pyblog/friday-qa-2009-11-06-linking-and-install-names.html and http://www.dribin.org/dave/blog/archives/2009/11/15/rpath/ you should
set the Installation Directory for your referenced framework(s) to #rpath
in the app set Runtime Search Paths to #loader_path/../Frameworks
and in the QuickLook plug-in set Runtime Search Paths to #loader_path/../../../../../Frameworks as suggested by catlan -
that way you don't need to duplicate referenced frameworks inside the QuickLook plug-in
Compile, run, and everything should just work if everything else is set up correctly.
In addition you might want to check the code-signing settings in your plug-in to make sure there's no problems there.
One thing you can do is remove (or turn-off) code signing from your app and then see if it will load the plug-in…
To check if code-signing is the problem you can turn it off temporarily for your app using the Terminal to codesign --remove-signature YourApp.app and see if it works..
Run Search Paths should be #loader_path/../../../../../Frameworks because it is installed into Main.app/Contents/Library/QuickLook/QuickLookPlugin.qlgenerator/Contents/Mac/QuickLookPlugin, so we need to go five folders down from the #loader_path to find the frameworks folder.
I have a project using MonoMac in Xamarin Studio. I'm using [DllImport ("rlimit")] to access a .dylib file. However, even though I have mapped rlimit to rlimit.dylib, a DllNotFoundException is still thrown.
The .dylib files are in the project and should be accessible, however they cannot be found.
I'm guessing that the files are either in the wrong place, or they aren't being detected for some reason.
You need to put the dylib anywhere mono can find it.
You can find out where mono looks for native libraries by doing this:
export MONO_LOG_LEVEL=debug
export MONO_LOG_MASK=dll
mono yourprogram.exe
and verbose lookup output will be printed to the terminal. On my system mono looks first in the directory where the executable is, so putting the dylib there is probably the easiest. Then mono asks the system to find the dylib (by trying to open it without a path). The system typically looks in /usr/lib and maybe a few other places (this is of course system-dependent), but in any case you can add a path for the system to look in by setting LD_LIBRARY_PATH to that path. In this case you'll do this:
export LD_LIBRARY_PATH=/path/to/dylib:$LD_LIBRARY_PATH
mono yourprogram.exe
Note that you do not need the .dllmap, mono will automatically append the appropiate suffix depending on the platform (.dylib on Mac, .so on Linux and .dll on Windows).
I am trying to create and then add the dylib to a project.
I created it by using the "Cocoa-Library" template and setting the type to "Dynamic" (not sure if it should be dynamic or static...). Then I created a simple obj-c class called Test and wrote a method in it that prints out something to console.
I compiled and used the generated .dylib file and put it in another project. Now whenever I try to use it, I get this message on runtime"
dyld: Library not loaded: /usr/local/lib/TESTLib.dylib
Referenced from: /Users/***/Library/Developer/Xcode/DerivedData/TestingDYLIB-axmoocnxbwznoyerfogosumqufxc/Build/Products/Debug/TestingDYLIB.app/Contents/MacOS/TestingDYLIB
Reason: image not found
I also created a Copy File phase and set the destination to "Frameworks". I still get the same error.
What am I doing wrong?
The issue is not where Xcode is looking for the library at compile time, which is what Simon Whitaker's answer addresses.
The issue is that the application which uses the dylib cannot find it at runtime. When an application is built that uses a dynamic library, it copies the install_name of the dylib into the output binary.
Creating a copy files phase and copying the dylib to the Frameworks subdirectory of the app's bundle is the right thing do do.
However, you need to do an additional step. You need to compile the dynamic library with an install_name appropriate for a bundle app. By default, a dynamic library is created with an install_name of /usr/local/lib. The app can't find your library there because it doesn't exist. Even if you put the library there, your users certainly won't have it, so that would be the wrong solution.
The right solution is bundling the library with the app. To set the install name for the dynamic library, go into the dynamic library project and set the "Dynamic Library Install Name" option to: #executable_path/../Frameworks/libmydynamiclibrary.dylib
Xcode is looking in /usr/local/lib/ for the library. If the library is in another location, add that location to your Library Search Paths:
Select project file in Xcode 4
Select the target, then click the Build Settings tab
Make sure All is selected in the filter bar (not Basic)
Scroll down to the Search Paths section and you'll find Library Search Paths in there
I'm having some trouble to embed my application with the log4cocoa framework.I've embed frameworks in my application before with no trouble, but I cannot fix this one.
First of all, this is my system out:
dyld: Library not loaded: #loader_path/Frameworks/Log4Cocoa.framework/Versions/A/Log4Cocoa
Referenced from: /Users/leandro/Documents/Projects/MLoggerApplication/build/Debug/MLoggerApplication.app/Contents/MacOS/MLoggerApplication
Reason: image not found
Well, I think done all necessary steps to get a framework working fine including the copy files phase and changed the installation directory over the build options to #executable_path/../Frameworks .
I hope problem clear enough to receive your help.
Thanks in advance.
Looks like your framework isn't being copied into your target. If a framework isn't part of the system (ie, you have to distribute it with your app), you need to not only link your executable against the framework but to copy it into your app's ./Frameworks folder.
To do this, add a Copy Files build phase, select "Frameworks" as the build phase's destination, then drag the framework (from your Frameworks folder in your Xcode project) under that Copy Files build phase you just created. If you already have a Copy Files build phase for Frameworks, then just use it instead of creating a new one.
Firstly, i mean, Joshua Nozzi is completely right about how is to embed an app with a framework!
But log4cocoa as a little different and could only realize that because it is an opensource code able for download at http://sourceforge.net/projects/log4cocoa/.
The framework could be used with this configuration by adding a "Copy Files build phase, but instead "Frameworks", select "Products Directory" as the build phase's destination, then drag the framework to that "Copy Files build phase.
The difference among this, and the other frameworks relies in this build variable: installation directory.It has as default value: "/Frameworks .
This variable can be accessed by right clicking on the log4cocoa(first item in the targets list), then select "Get Info" and finally "build".
To use it as "normal" framework rebuild it after you have edited the "installation directory" value to "#executable_path/../Frameworks" or if you are going to embed a framework with it, you would prefer "#loader_path/../Frameworks"