Trying to setup and get going with the RestKit library for a cocoa project (NOT iOS) and have followed the instructions precisely at RestKit Installation on Xcode 4.x as a Git Submodule
The issue now is when I try and run and I get the following issue inside RKObjectManager when RestKit tries to compile for the first time:
defaultMappingQueue = dispatch_queue_create("org.restkit.ObjectMapping", DISPATCH_QUEUE_SERIAL);
Undeclared identifier 'DISPATCH_QUEUE_SERIAL' ?!
Any ideas what may be causing this? I'm linking all the correct libraries to the target as stated in the instructions.
DISPATCH_QUEUE_SERIAL is only defined on the OS X 10.7+/iOS 5.0+ SDKs. If you're building with an older SDK, you can pass NULL for the second parameter to dispatch_queue_create(). (Private concurrent queues won't work on older OSs, though.)
Related
I have followed the NativeScript documentation on adding Objective-C code to a NS project although I am struggling to call the Objective-C code in my iOS project. I am only trying to implement appPlugin.h and appPlugin.m files into my project.
My folder structure for the Objective-C files are as follows:
Project/app/App_Resources/iOS/src/...
I have also tried creating a NativeScript plugin that gets added to the dependencies in the projects package.json.
Are there any additional files that need to be added to make the Objective-C code compatible with the NS project. The documentation simply says run "If you run 'tns prepare ios' you will see that the files are now part of the project."
Link to the documentation I have been following:
https://www.nativescript.org/blog/adding-objective-c-code-to-a-nativescript-app
https://docs.nativescript.org/plugins/building-plugins
SOLVED: Files are added to the TNSNativeSource folder (Check in Xcode) and are available to use like any JS object.
I have managed to get react-native-fbsdk (core, login and share) all working in my project. I can build to devices without issue but if I try to create an archive from Xcode I get the error
Lexical or Preprocessor Issue
'RCTBridgeModule.h' file not found
I have followed the install instructions and create a virgin project and done it again to ensure nothing else could be causing this.
Similar Xcode related questions have come up blank for me too:
Xcode 4 can't locate public header files from static library dependency
When archiving app Xcode complains about missing files
Xcode 4 and nested projects -- header files not found
This makes me wonder if there's something else to to with FBSDK specifically that I need to do to get it to archive properly.
Has anyone got a project to archive with react-native-fbsdk? If so, how?
Note: I skipped the step regarding explicitly naming the path for static libraries as I do not know what the name should be; I do not know which the static library would be fbsdkcore (etc) or react-native/react.
I appears that the repo had an error in its header search paths in 'release' distribution. The fix was to correct the xcodeproj in the plugin (A PR is currently going through for this) as outlined here
The following line is present in the debug distribution but not in release for any of the required xcodeproj's
"$(SRCROOT)/../../node_modules/react-native/React/**",
Adding this fixes the error.
Full Source Code Alterations
I'm working on a project that uses both RestKit and CocoaLumberjack. The project also uses some other pods, some of them only exist in swift. I use cocoapods 0.38.2 for dependency management, my podfile looks like this (removed other pods for readability):
source 'https://github.com/CocoaPods/Specs.git'
platform :ios, '8.0'
use_frameworks!
pod 'RestKit'
pod 'CocoaLumberjack'
I need to use use_frameworks! because of those other pods that are swift-only. I try to compile this using Xcode7 beta 5, I get the following errors:
"_OBJC_CLASS_$_DDLog", referenced from:
objc-class-ref in RKLumberjackLogger.o
ld: symbol(s) not found for architecture x86_64
So I took a look into the offending file and found this:
#if __has_include("DDLog.h")
#import "RKLumberjackLogger.h"
#import "DDLog.h"
Looks like the entire file resolves to nothing if the DDLog.h is not present, in which case I think the RestKit logging falls back to NSLog or whatever. Otherwise, the Lumberjack logging is used, which is what I want.
After some investigation, my suspicion is that the RestKit somehow sees the CocoaLumberjack headers (where the DDLog.h is), but is not properly linked against it when the project is built. Feel free to question this in case you have better ideas, but I can confirm that going to the CocoaLumberjack sources and manually adding DDLog.m as a member to the RestKit framwork target allows me to compile the project properly.
So, my question is, what is the correct way of fixing this? RestKit is not directly dependent on CocoaLumberjack, but tries to detect it and use it if possible, but fails miserably. Is there a way to link RestKit with Lumberjack from my project level so I don't have to modify the pods?
Example project can be found here
Your suspicion is correct.
RestKit somehow sees the CocoaLumberjack headers (where the DDLog.h is), but is not properly linked against it when the project is built
This is a problem with RestKit and everything that you would do within your own project would be a workaround. So arguably, there is no single correct way to fix this in your project.
I have filed a Pull Request with a fix for this issue.
Update:
The pull request has been merged, but at the time of writing this update, no new version of RestKit has been released yet.
pod "RestKit", :head, :subspecs => ['Core', 'CocoaLumberjack']
RestKit's Lumberjack logging functionality has been moved into a separate subspec that you have to specify if you want to use it.
:head will tell CocoaPods to use the current master instead of a released version.
I am trying to use a method from a DLL in a OSGI-bundle. The DLL gets loaded correctly in OSGI, but I still get an java unsatisfied link error, the native method is not found!
When deployed standalone in Java only (no OSGI), the DLL gets loaded and run perfectly.
Here's what I did:
I generated a JNI bridge to my C++ compiled DLL through SWIG.
I specified the package name when calling swig.
I declared the dll inclusion in my Maven pom.xml xml element, which generates a correct Manifest file.
Loading of the DLL libraries is done without any errors / warnings
What truly puzzles me is that the symbols in the dll seem to not be found:
java.lang.UnsatisfiedLinkError: com.bmw.corona.components.sample.impl.generated.AdasDeconstructorJNI.swig_module_init()V
The problem is when coupling it with OSGI, I'm guessing somewhere in OSGI's ClassLoader.
The method in the dll seems to have a the correct signature :
_Java_com_bmw_corona_components_sample_impl_generated_AdasDeconstructorJNI_swig_1module_1init#8
with the following prototype in the generated SWIG file:
SWIGEXPORT void JNICALL Java_AdasDeconstructorJNI_swig_1module_1init(JNIEnv *jenv, jclass jcls)
I was triple-sure to check that the Manifest includes the Bundle Native instruction.
What am I doing wrong?
You may want to consult this wiki article: http://wiki.osgi.org/wiki/Dependencies_In_Native_Code
It is hard to tell from your description, but it sound like you have 2 native libs. One with the JNI entry points and the other with the real native function. The above wiki article discusses the dependencies from the JNI native lib to other native libs.
The problem was twofold. First, the methods weren't found do to Visual Studio 2010's method name mangling. I added a linker directive :
#pragma comment(linker, "/EXPORT:__Java_com_bmw_corona_components_sample_impl_AdasDeconstructorJNI_swig_module_init=_Java_com_bmw_corona_components_sample_impl_AdasDeconstructorJNI_swig_1module_1init#8")
It does take a bit of time for all the bundles (more than 100) to get up and running, and I do get a java.lang.NullPointerException: null the first couple of seconds after launch. Afterwards, everything seems to be working fine. And the nullPointerException is gone..
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