How do you use ShareKit with MonoTouch?
The MonoTouch Bindings project on GitHub seems to have bindings for ShareKit but I can't get them to work. I currently have an iPhone application developed using MonoTouch in MonoDevelop, but I have no idea how to actually get ShareKit into my application.
I've downloaded the MonoTouch Bindings project, but when I make in the ShareKit directory it seems to require ShareKit itself. I then downloaded ShareKit, but I'm not sure if I'm supposed to follow the installation instructions for integrating ShareKit into an XCode project or even whether I'm supposed to build ShareKit at all. I've tried "building" an empty iPhone application project with ShareKit but parts of the instructions are not up-to-date for the latest XCode, it seems, to I got stuck in the process. I'm trying to get this working but my experiences with XCode so far has been limited to what little's needed for MonoTouch development.
Or is there a "precompiled" ShareKit iOS binary that could be used with MonoTouch?
Could someone verify that ShareKit is actually usable with MonoTouch and walk me through the steps required for making it work?
Thanks in advance!
Most of the time when getting going with bindings in MonoTouch you have to download the bindings (or SDK) of the actual library. For example, with the TestFlight bindings, you are required to download the SDK and place it in the same directory as the makefile. I haven't personally expieremented with ShareKit, but I suppose it would work the same way (I know for a fact most, if not all, of the bindings in the MT bindings GitHub project work that way). You shouldn't have to deal with Xcode at all. Just download the SDK, place it in the correct directory, and run the makefile. That should spit a DLL for you to reference for use with MonoTouch.
One of the limitations of using the ShareKit bindings is that, as far as I know, the UI adjustments must be done in Objective-C before you try and use the linker. If you are fine with the out-of-the-box UI, then I would go for it. Otherwise, there are plenty of other open-source libraries for creating a simple sharing dialog (and now that Twitter is built in to iOS, it is even easier).
First did you download from getsharekit.com or are you using ShareKit 2.0? If you are using the DL from getsharekit then I highly recommend you upgrade first. Second here some basic installation instructions for getting ShareKit to work with MonoTouch:
Steps
1) Download the code
2) Open in Xcode and if its an App create a new Xcode project of type iOS library
3) Compile the library and take note of the frameworks needed - these will help you later when linking in monotouch
3) Compile a i386 Sim version of the lib and rename to libXYZLib_Sim.a - copy this to /Lib in your project and set its build action to None. You can find this under /ProjectLib/build/Debug-iphonesimulator/
4) Compile a arm6 version with the correct version & copy this to /Lib in your project and set its build action to None. You can find this under /ProjectLib/build/Debug-iphoneos/
5) Run the NovellHeaderParser like so against the library directories that contain .h files
##
mono "/Users/XX/Projects/NovellHeaderParser/NovellHeaderParser/bin/Debug/NovellHeaderParser.exe" /Users/XX/Documents/ShareKitLib/ShareKit/Core
##
this should produce a MonoMac.cs file that you can import into your system
6) Repeat step 5 for other directories. NOTE you will really only have to run the parser against .h files with entry points e.g. top level classes that the API calls directly. subclasses, utils, helper methods don't need to be parsed.
7) Combine all the MonoMac.cs files into a new MyLib.cs file and add that to the project under /Lib - set its build options to None
8) Change any references from MonoMac to MonoTouch
10) The parser might create a enum.cs file for each directory parsed but if not create your own called MyLibEnum.cs with any structs or enums needed by the API - add it to /Lib and set build options to None
11) Open a terminal window and navigate to the /Lib dir of your project
12) run the following btouch command line - this will create a wrapper.dll from the interfaces defined in MyLib.cs
##
/Developer/MonoTouch/usr/bin/btouch -v MyLib.cs -s MyLibEnum.cs
##
13) Add any missing enums or structs to MyLibEnum.cs and repeat Step 12
14) Fix any multiple declarations of selectors by renaming them - this may cause a problem later (see note 1)
15) Fix any missing references e.g. NSMutableArray does not seem to exist in monotouch so I change these to NSArrays (I think these are mutable under monotouch anyway???)
16) Go back to 12) and repeat until a dll is generated.
17) Add a reference to the dll into the project
18) Add the following into the iPhone Build> additional mtouch options TO THE SIMULATOR DEBUG/RELEASE BUILD:
##
-gcc_flags "-L${ProjectDir}/Lib -lMyLib_Sim -framework QuartzCore -framework CoreGraphics -framework MessageUI -framework Security -framework UIKit -framework CFNetwork -force_load ${ProjectDir}/Lib/libMyLib_Sim.a -ObjC"
##
'''Notice'''
no trailing / on -L${ProjectDir}/Lib
-lShareKitLib_Sim does not need need the starting lib prefix or .a suffix
add one -framework for each framework used in the creation of the lib - above is not an exaustive list
19) Add the following into the iPhone Build> additional mtouch options TO THE IPHONE DEBUG/RELEASE BUILD:
##
-gcc_flags "-L${ProjectDir}/Lib -lMyLib -framework QuartzCore -framework CoreGraphics -framework MessageUI -framework Security -framework UIKit -framework CFNetwork -force_load ${ProjectDir}/Lib/libMyLib.a -ObjC"
##
20) TEST IT!
Related
I'm trying to build llvm 3.4.2 on CentOS 7 with GCC 4.8.5. I can successfully build all of the libs, except libLLVM-3.4.so doesn't want to build - everything else gets created except that one. What's worse is I've managed it previously in the past, but can't do it again now.
I've tried both with CMake and autotools, with the same result. Is there an option I'm missing? Or some error in configuration possibly?
Found it - it was the --enable-shared flag to configure which causes the main shared library to be built. Confusingly this does something completely different from the CMake BUILD_SHARED_LIBS variable, which causes each of the individual libraries to be built as a shared library instead of static, but doesn't build the main shared library.
You can use
LLVM_BUILD_LLVM_DYLIB
when building from source.
The official docs say
BUILD_SHARED_LIBS is only recommended for use by LLVM developers. If you want to build LLVM as a shared library, you should use the LLVM_BUILD_LLVM_DYLIB option.
source: https://llvm.org/docs/CMake.html
Using Android NDK R10E, I am trying to build a shared library for all supported ABI's and I am getting the following error for some but not all ABI's:
[armeabi] SharedLibrary : libMyLib.so /home/user/android-ndk-r10e/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.8/../../../../arm-linux-androideabi/bin/ld:
fatal error: /home/user/source/MyLib/obj/local/armeabi/libMyLib.so: Input/output error
The project successfully builds for arm64-v8a, mips and mips64 but fails with the above error for armeabi, armeabi-v7a, x86 and x86_64.
I have a static library project and another shared library project and they both build successfully for all 7 ABI's.
If I compare the contents of obj/local/ for an ABI that builds and one that does not, they both contain all the same files except for libMyLib.so.
The difference between those two sets of ABIs is that the failing ones link using ld.gold and the working ones use ld.bfd.
Two things to try:
Use the 4.9 toolchain. It hopefully has the bug fix.
If that doesn't work, you can add -fuse-ld=bfd to your ldflags to use bfd even on the architectures that default to gold.
Same issue happened to me in r15c.
The fix was to copy
android-ndk-r15c/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/arm-linux-androideabi/bin/ld.bfd over ld.
I had to copy it because I could not easily find a way to specify this flag to CMake to use it while detecting the compiler features.
First of all I must say I'm new to Android NDK development.
I'm trying to compile a working engine (openGL and openCL based) with the NDK to use it in Android.
I have variables in the headers and cpp files defined to separate the OpenGL 3.0 code and the OpenGLES 2.0 one.
Anyways, in the Android.mk file I recursively add all the .cpp files in the folders and subfolders when compiling so no code differentiation is performed and the compilation fails.
How can I work around this?
(I'm using Eclipse Luna CDT + ADT in MAC OSX)
Ok, this is done via the Android.mk file adding the flags:
LOCAL_CFLAGS := -DANDROID_NDK
This defines the MACRO "ANDROID_NDK"
Then in the code use:
#ifdef ANDROID_NDK
...
and so on.
I wonder if anyone did managed to build the fresh SDL2 with the toolchain of the Android NDK(r8d).
SDL2 seems to be very close to the release (since yesterday it isn't "UNDER CONSTROCTION anymore: http://hg.libsdl.org/SDL/rev/0a3d2ec7af6d). It comes with an Android.mk and just compiles fine following the instructions in the bundled README.android file. My question is whether there's really no working automake based build is available or will be available to compile it on Android, or something's wrong with my toolchain setup?
I have installed the NDK toolchain following the instructions of the documentation located at $NDK/doc/STANDALONE-TOOLCHAIN.html. I'm using gcc 4.6. Here's one environment i use:
#!/bin/sh
export TOOLCHAIN=$HOME/Android/android-14-arm
export PATH=$TOOLCHAIN/bin:$PATH
export SYSROOT=$TOOLCHAIN/sysroot
export CROSS_COMPILE="arm-linux-androideabi"
export CC=$CROSS_COMPILE-gcc
export CXX=$CROSS_COMPILE-g++
export CPP=$CROSS_COMPILE-cpp
export CFLAGS="-march=armv7-a -mfloat-abi=softfp -mfpu=neon"
export LDFLAGS="-march=armv7-a -Wl,--fix-cortex-a8"
echo "Compiler set up for ARM 14"
The configure params:
./configure --host=arm-linux-androideabi --prefix=$SYSROOT/usr/local
With the same configuration i successfully built libjpeg-turbo v8 and SDL_image.
The configure script recognizes the cross-compiler, and builds the makefile, however, it finds X11 support, can't see the OpenGL ES... The make fails:
In file included from /usr/include/features.h:378:0,
from /usr/include/sys/types.h:27,
from ./include/SDL_stdinc.h:35,
...
I checked the configure log, i have no idea where the "/usr/include" comes from.
But in fact, the generated makefile adds that line in the EXTRA_CFLAGS to the compiler.
The NDK doc refers the --with-sysroot=$SYSROOT as optional, i've included it to see if it solves the problem, but that didn't help.
As a last effort i manually edited the Makefile, fixing that reference, and now the compiler complained about X11.h.
AFAIK Android has nothing to do with X11, so i guess the whole build-tree completely inappropriate to use with NDK.
I have also tried a different configuration, found in an older thread here.
Neither defining -DANDROID -mandroid -fomit-frame-pointer nor changing back to -march=armv7-a -mfloat-abi=softfp -mfpu=vfp -mthumb" solved the problem.
On previous projects, i had to refresh config.guess, and config.sub in order to get my compiler recognized. SDL doesn't seem to use those. Furthermore no Makefile.ac or Makefile.am comes with SDL to work with, and no templates for other platform could be used for a good starting point to create my own makefile. Additionally, i've never had to deal with makefiles, i really have no chance to sort out these problems. Even if it succeeds, i will probably need a configure tool as well, since i have no idea how ndk-build manages to install SDL2 without configure scripts.
Compiling the SDL sources with the project together is the only working - but ugly solution. I would like to deploy the necessary lib and header files by make install.
I hope the solution is something really easy and obvious thing that i just didn't think about...
This issue has been fixed at http://hg.libsdl.org/SDL/rev/4e57cfd9fca8 and expected for the 2.0.4 release. Note there are newer revisions with some related fixes about defines.
cmake_minimum_required(VERSION 2.8 FATAL_ERROR)
project(ImageProc)
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
find_package(PCL 1.2 REQUIRED)
find_package(OpenCV REQUIRED)
add_definitions( -fPIC -Wall -O3)
include_directories(${PCL_INCLUDE_DIRS})
#link_directories(${PCL_LIBRARY_DIRS}) Dont think neccesary..
add_definitions(${PCL_DEFINITIONS})
add_executable (ImageProc svm.cpp ImageProc.cpp testImageProc.cpp)
target_link_libraries (ImageProc ${OpenCV_LIBS} ${PCL_LIBRARIES})
add_library(ImageProcLib STATIC svm.cpp ImageProc.cpp)
target_link_libraries (ImageProcLib ${OpenCV_LIBS} ${PCL_LIBRARIES})
Currently, I run this and open with VS C++ and generate an exe and lib.
The exe runs on my machine.
Current limitations:
When I pass the exe to my friend, he cant run it on his machine as he gets hit by host of missing dlls.
When I use the lib files, to create a new project in VS C++, there is a fatal error in not finding a header file.
I know, I can manually add all the dlls and or package all the header and library files for the lib. But it is definitely cumbersome and ugly also.
Question:
Does CMake offer a way, so that when compiling into
An exe (it will automatically find all the necessary dlls into bin directory)
Into a lib (it will automatically source out all the header files and also the neccesary library for the linking part into the lib directory)
Preparing your package for deployment on other development environment can still be a tough task. You will need to setup your own interfaces/API correctly and will need to deal with cross-dll issues, different runtimes, etc.
However, there are a few tools from CMake at your disposal:
Check out the Install and Export. You can use it to specify (in your CMakeLists.txt) which files are necessary for deployment. This way, you can mark which header-files, but also which targets (libs and exes) should be deployed.
Also take a look at CPack in combination with NSIS, which can be used to build NSIS installers of your project.
Together with the InstallRequiredSystemLibraries and BundleUtilities you can then prepare an install or package target. See also this and this question demonstrating how third-party dlls can be added to such a deployment package.
InstallRequiredSystemLibraries is very useful for appending vcredist to your own package installer, which you will surely need if you are installing your project on a non-development pc.