I have a C lib and dll file from windows application. No source code with me.
Is it possible to use that in an IOS application.
I have seen mixed responses and am confused.
If we have source code , i think we need to create dylib and then we can use the same after including relevant header file.
Please share any expert ideas to guide me in right direction.
Appreciate your help .
mia
Dynamic Libraries are not permitted on iOS to begin with, but above that, the DLL file format is not recognized by Darwin or the underlying XNU Kernel at all, as the binary format is different.
Windows APIs are not usable on the Darwin OS either (Both Mac OS X and iOS are wrappers around the basic Darwin OS). You will need to rewrite the code from the DLL to use the POSIX and/or Objective-C APIs and compile it as a static library to use it.
You need to get a iOS compatible library, no other way around it. There are several reasons:
iOS doesn't support DLLs as they are windows format, but moreover, you can't use any dynamic library on iOS, as Apple restricts it.
DLLs are usually for intel CPUs, while iOS devices have ARM CPUs.
Most dlls are calling windows APIs - are you sure this one's not?
No. If you all you have is a compiled binary DLL, there is no way to use it on iOS. Unless you happen to have an ARM DLL for the upcoming Windows 8, your DLL contains either x86 or x86-64 machine code (or maybe IA64 if you have a lot of money), which absolutely will not run on iOS devices, which are all ARM architectures. Plus many more reasons.
If you have the source code, you can recompile it for iOS, either directly into your app, as a static library that can be linked in with your app, or as a dynamic library as part of a framework. But in all cases, you need to recompile it from source code using the iOS compiler.
You are going to have to recompile it as a static library (.a file). Apple doesn't allow dynamic libraries except for their own frameworks (so you can't compile it as a dylib).
Related
I was trying to get the header files from the ToneKit framework on iOS7.1, but I found that I cannot use class-dump because there are no executable files inside the framework. From what I have found after some research, it seems as if the actual executable file is inside the dyld_shared_cache on the device. After reading this article, it seems as if there are some tools to decrypt the cache, but since iOS 3, Apple has implemented ASLR which has made the decryption tools not work. How can I extract the Frameworks from inside the dyld_shared_cache on iOS7.1?
I am very new to jailbroken ios development so please bear with me.
If you're interested in how they got those headers then the answer is very simple - iOS SDK. SDK contains ARM binaries of public and private frameworks because they are required to compile iOS applications. Class-dump them and you will get headers you need. ToneKit.framework binary is also in there.
Usually you don't need dyld_shared_cache, almost everything you need is either in iOS SDK or on a device itself like SpringBoard, other system applications etc.
Of course there are rare cases when dyld_shared_cache is the only place you can find certain binaries as they are missing from both iOS SDK and device. In that case I use IDA. It has free demo version that can open dyld_shared_cache files - you can even open individual binaries inside it rather than dump everything. You just need to copy dyld_shared_cache on your PC.
I think Elias Limneos's classdump-dyld can help you. If not, check out RuntimeBrowser. Failing that, even, weak-classdump has proven to be a very useful runtime tool for me.
Suppose I've read this caveat, and I still want to use TBB as a statically-linked library. (Pretend I'm working in an environment where users aren't allowed to create their own dylibs.) But I don't really want to rewrite the TBB makefile to generate libtbb.a instead of libtbb.dylib.
Is there a simple command-line way to convert libtbb.dylib into libtbb.o with the same entry points?
I have heard a good argument for not being able to go the other way, from static to dynamic. Namely: dynamic libraries need to be PIC, and converting a non-PIC static library to PIC isn't feasible. But that argument doesn't apply in the other direction, as far as I know.
Here's someone saying it's impossible to convert .dll to .a on Windows, but I think they're just talking about the impossibility of breaking a .dll or .exe back up into its original .o files, not necessarily saying it would be impossible to create a linkable .o file with the same contents. Also, the situation on Windows is slightly odder than "real" PIC, although I don't think that's relevant.
Intel Threading Building Blocks (TBB) is available as binary for Windows, Mac and Linux. If you expect to use libtbb.dylib from the Mac distribution on iOS then you are out of luck. The Mac distribution is targeted for Intel (32 and 64 bits). Since iOS runs on ARM processors, you could not use it, even if you found a way to convert a dynamic library to a static library.
If you found a libtbb.dylib file somewhere else targeted for ARM, then you could probably use it on iOS. It's actually possible to load dynamic libraries on iOS. Have a look at the dlopen(3) man page.
Finally, you should read about Grand Central Dispatch (GCD) instead, which is built-in support for concurrent code execution on multicore hardware in iOS and OS X.
So on iOS Apple won't let you release an application that has a dynamic library (dylib). (Xcode won't compile it although there are workarounds, and the app store won't approve it.)
We have an SDK that we are currently moving from Windows to iOS. On Windows, we statically link all of our dependencies into one dll, so we only have to provide 1 file to anyone using the dll, so we don't have to publicly release all of the libraries that we are using and to keep the size of that file small, since any parts of those libraries that we aren't using get compiled out.
On iOS, since it's not possible to release an application that loads a dynamic library, we would be forced to ship a framework or something like that, which includes all of the libraries that we link against. The developer consuming our sdk would then compile our lib with all of its dependencies into their application.
This would let anyone using our SDK know what libraries we're using and would increase the size of our deliverable, since it would have to include full version of all the libraries we're linking against. (At least with a framework we would still only be providing 1 "file".)
Is there any way that Apple allows to avoid letting everyone know what libraries we're using?
I am attempting to get a Native C/C++ library working with Monodroid in the emulator, using DllImport. I am developing mainly in Windows/Visual Studio 2010.
I have built a native C/C++ library (ZeroMQ) using the Android NDK tools, to both x86 and armeabi platforms, using a Ubuntu virtual machine. Is this correct - x86 for emulator and armeabi for the real device? (This is certainly the case on the iPhone/MonoTouch - though in that case statically linked libzmq.a file and DllImport __Internal)
I have added the x86 version of libzmq.so to my MonoDroid project under the directory structure lib\x86\libzmq.so
When I first attempted to build/deploy to the simulator, I got an error 'cannot determine abi type', so I've added x86 to the AndroidNativeLibrary Include="lib\x86\libzmq.so"> project item group. This then deployed.
I have a DllImport for the function to call [DllImport("libzmq"
I've tried libzmq.so, lib/x86/libzmq, lib/x86/libzmq.so etc, but then I call the DllImported method (running in the emulator), I always get a DllNotFoundException.
Can anyone give me some direction?
EDIT: After reading another support answer which states that the emulator uses armeabi .so libraries, I have removed the x86/libzmq and added my lib/armeabi/libzmq.so as an AndroidNativeLibrary. I also removed the project file Abi entry, and indeed the project built and deployed fine.
However, I still get a DllNotFoundException when I try to call a DllImported function. Any ideas?
Many thanks
I don't have any immediate ideas why it isn't working for you; [DllImport("zmq")] should work.
The SanityTests sample exercises the DllImport attribute.
The DllImport: https://github.com/xamarin/monodroid-samples/blob/master/SanityTests/Hello.cs#L240
The Android.mk to build libfoo.so: https://github.com/xamarin/monodroid-samples/blob/master/SanityTests/jni/Android.mk
Building libfoo.so by calling ndk-build: https://github.com/xamarin/monodroid-samples/blob/master/SanityTests/SanityTests.csproj#L82
Including libfoo.so into the .apk: https://github.com/xamarin/monodroid-samples/blob/master/SanityTests/SanityTests.csproj#L96
(This is a repeat of my reply to your email in the ZeroMQ mailing list).
This error could be caused by using an incorrect platform target in your Mono project. I'm not sure if Mono/MonoDevelop supports this, but you probably need to create an ARM platform target, as opposed to x86/x64/Any CPU.
You would experience the same errors if you tried to do P/Invoke interop between an x64-targeted assembly with an x86 native library or vice-versa.
If you're using the clrzmq bindings for bridging Mono and libzmq, you will need to create a new platform target for ARM and rebuild the bindings. The solution only defines x86 and x64 platform targets currently.
Ok, I finally got it working! For whatever reason, ZeroMQ doesn't build correctly using the current/latest NDK r7. The instructions at http://www.zeromq.org/build:android use NDK r6. I also downloaded an old version of the NDK r5b (it was the easiest old version to find a download for), and rebuilt ZeroMQ using it. Result, it now works on emulator and phone!
Has anyone used Bluetooth on Mac OS X with Lazarus or FreePascal? There is a bluetooth unit, but it currently only supports Linux.
Information about existing unit:
http://wiki.freepascal.org/Bluetooth
I plan to enhance this to support Mac OS, but it would be nice to know if anyone has written any code to use BlueTooth on Mac OS already to avoid duplicated work.
On the other hand, if you have used XCode to access Bluetooth, what libraries did you use? I am sure I can discover this with the XCode profiler by opening some Bluetooth applications.
Note: Mac OS X doesn't appear to use the BlueZ library that Linux has, so I don't think the solution is as easy as changing the library path. Instead, it has IOBluetooth "Framework", located at /System/Library/Frameworks/IOBluetooth.framework.
Having a look, it looks like:
kaikei.ocn.ntt.com:IOBluetooth.framework $ file *
CodeResources: XML document text
Headers: directory
IOBluetooth: Mach-O universal binary with 3 architectures
IOBluetooth (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
IOBluetooth (for architecture i386): Mach-O dynamically linked shared library i386
IOBluetooth (for architecture ppc7400): Mach-O dynamically linked shared library ppc
Resources: directory
Versions: directory
On the other hand, I think if anyone had done this already, I would probably be able to find it on Google.... On the off chance I am wrong, please reply and let me know.
Clarification: I have created bindings for normal shared libraries before (f.e. sqlite3), but not for a "framework". If nobody has created bindings or otherwise used the MacOS Bluetooth framework from FreePascal, advice on how to use framework functions from FreePascal in general woule be appreciated. (And normally the functions I am porting are C based, not Obj-C, so I am not sure how to declare Obj-C methods in FPK, although I am sure I will be able to find some samples if I keep searching).
The main svn repository for translated Mac OS X framework C headers is http://svn.freepascal.org/svn/macosxintf/trunk
From time to time, FPC releases are synchronised with the latest versions hosted there. Note that the files in that repository (in the MPPInterfaces subdirectory) are in a generic format that can be automatically translated into either FPC, GPC or CodeWarrior Pascal versions.
To generate the FPC versions, use "make fpcpinterfaces", and find the results in the Build/FPCPinterfaces folder.
To translate new headers, execute something like this from inside a checked out copy of the macosxintf repository:
./Scripts/Convert.pl /System/Library/Frameworks/IOBluetooth.framework/Headers/IOBluetooth.h FORCE MPPInterfaces
Afterwards, you'll still have to edit the resulting file to add/remove units and clean up some other things not handled by the automatic translation process. Once finished, you may want to submit a bug report at bugs.freepascal.org with the finished units.
(note: because I'm unregistered, I can only add in one url per post, so the next url's are a bit mangled to get around that restriction)
You can also subscribe to the Mac Pascal list (lists.sonic.net/mailman/listinfo/mac-pascal) and ask there whether someone already translated those headers.
The Bluetooth framework indeed also contains some Objective-C headers. Objective-Pascal support is only available in the latest FPC svn versions, as described on the FPC wiki (google FPC_PasCocoa). You need this support in order to interface with Objective-C.
Translating Objective-C is probably easiest using the script elsewhere in FPC's svn (svn.freepascal.org/svn/fpc/trunk/packages/cocoaint/utils/)
You may want to ask for help on the above-mentioned Mac Pascal list, as all people maintaining the aforementioned translations and translation tools are subscribed there.