can't load OcMockito - objective-c

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 :)

Related

Debugging QuickLook plug-in with 'bundle is damaged' error

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.

How to load a dll in Karaf container?

I have a dll which provides a simple functionality (called HelloCpp.dll) and
I need to access to the content of this library from Karaf container via REST calls.
I created a simple maven bundle which provides the REST api and a class (HelloJNI) which loads HelloCpp.dll using: System.loadLibrary("HelloCpp");
I have also addressed this dll in my POM file using: <Bundle-NativeCode>HelloCpp.dll</Bundle-NativeCode>
I have coppied the dll in both project directory and also karaf/lib folder.
I can successfuly install the bundle and I don't receive any compilation error as well, but when I deploy my bundle into Karaf container and try to start bundle, I get this error message: No matching native libraries found.
Could you please help me to solve the problem? Maybe I don't address the dll correctly in the POM file.
Thanks in advance,
Mandana

Cocoa Screensaver plugin with bundled custom frameworks

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.

Using the ConnectionKit Framework Within an NSBundle

Update
I've since spent time learning how to use install_name_tool & otool to do this properly, and documented the process here: Using Frameworks Within NSBundles
I would like to use the Connection Kit framework within an NSBundle I am making.
To allow my bundle to load the framework successfully, I've changed the dynamic library install name to use #loader_path as opposed to #executable_path.
After building and including the framework in my NSBundle, then building that, running the program that loads my bundle, my bundle fails to load and produces the following output:
Error loading MyBundle.rwplugin/Contents/MacOS/MyBundle: dlopen(/Users/facelap/Library/Developer/Xcode/DerivedData/MyBundle-hiyhdkndcnuhspfqwcuyneqobeou/Build/Products/Debug/MyBundle.rwplugin/Contents/MacOS/MyBundle, 265): Library not loaded: #executable_path/../Frameworks/DAVKit.framework/Versions/A/DAVKit
Referenced from: /Users/facelap/Library/Developer/Xcode/DerivedData/MyBundle-hiyhdkndcnuhspfqwcuyneqobeou/Build/Products/Debug/MyBundle.rwplugin/Contents/MacOS/../Frameworks/Connection.framework/Versions/A/Connection
Reason: image not found
It seems that Connection Kit itself uses a framework.
I also have the source for this framework. I tried setting its dynamic library install name to #loader_path, but this resulted in similar output (and the bundle failed to loar).
What would a sane entry be for the dynamic library install name for a framework within a framework that is to be used within an NSBundle?
Look at the crash log. It says that you bundle can't load DAVKit.framework so the easiest way - its rebuild ConnectionKit framework but instead of embedding DAVKit.xcodeproj insert all sources of DAVKit. Its easiest way but more correctly - its setup install path of ConnectionKit and DAVKit frameworks.
Its link should help you:
embedding frameworks in loadable bundles
You should link your bundle with DAVKit and include it there In the same way as you're including ConnectionKit. This avoids having multiple depths of frameworks being shipped

Using a framework in a PreferencePane

i am currently trying to implement a "third party framework" (FeedbackReporter.Framework) into my preferencepane.
Unfortunately I am getting the following error all the time when trying to launch my preference pane:
16.05.10 23:13:30 System Preferences[32645] dlopen_preflight
failed with
dlopen_preflight(/Users/me/Library/PreferencePanes/myPane.prefPane/Contents/MacOS/myPane):
Library not loaded:
#executable_path/../Frameworks/FeedbackReporter.framework/Versions/A/FeedbackReporter
Referenced from:
/Users/me/Library/PreferencePanes/myPane.prefPane/Contents/MacOS/myPane
Reason: image not found for
/Users/me/Library/PreferencePanes/myPane.prefPane
As far as I read so far, this problem is probably caused because my prefPane is no actual app, but a "plugin" of "System Settings.app" and thus #executable_path resolves to a path within the bundle of this app, instead of the bundle of my prefpane.
But I don't really picked up howto fix this problem. I guess it must be fairly easy since it should be a usual case that people use non-apple-frameworks in PreferencePanes.
Thanks for your hints!
--
Short Update:
As far as I understood tons of docs I read so far, there might be a setting which has to be done in the third-party framework. Obviously the "install path" has to be set to "loader_path" instead to "executable_path" in order to work in a preferencepane.
But since I am using a precompiled framework (FeedbackReporter.framework) this is probably a setting which the author has to change?! and even if i could compile the framework myself, i had no idea where to change this install_path in Xcode.
If you cannot wait for the next release just download the source, change it in
FeedbackReporter.xcodeproj/project.pbxproj
and then open and compile the framework yourself.
Actually, you can change it yourself without recompiling the third party framework. You can use install_name_tool to change where a MachO binary will look for shared object libraries. First use otool -L <binary file for your plugin> to get the paths of where it expects its libraries to be, then use install_name_tool -change ... to change the paths in that file. Repeat for any bundled frameworks.