Is it possible to link a C# library compiled using monotouch with an objective-C front end in a single application, or does the app have to be all or nothing?
It is possible but you aren't going to get any help from the MonoTouch tooling and you can't get away from the fact that you still have to have the Mono runtime to execute your C# code.
In order to provide the Mono runtime to the Objective-C app, the runtime will have to be embedded into the app. The MonoTouch site has some docs on how to do this here and you can find more technical details about embedding Mono into your application here.
MonoTouch, when compiling your C# code, produces .m and .s files that are used by Objective-C to call that code. These files will need to be included in the consuming Objective-C project but MonoTouch cleans up those files after they've been used. In order to keep mtouch, the MonoTouch compiler, from deleting the .m and .s files, use the --keeptemp option when invoking the compiler. You can find a good sample Makefile here to help you figure out how to call mtouch correctly from the command line.
Finally, you will need the full version of MonoTouch in order to do this. The trial version will not generate the .s files.
Related
I'm exploring Swift with Xcode-6 and so far so good although I think the new collections need a little bit of work as I've managed to break the compiler a few times.
Problem is I'm now stuck trying to create the framework package to then use in another project. The project builds without issue and all tests pass successfully. When I go to create Archive (which I assume is what is required) I receive the error:
:0: error: underlying Objective-C module 'Sample' not found
Now I assume this has something to do with the contents of my Sample.h which tells me
// In this header, you should import all the public headers of your framework using statements like #import <Sample/PublicHeader.h>
which is fine except I have only used swift enums, structs and classes for this framework so therefore no .h files exist.
Can anyone shed some light on this one as I can't find any documentation available yet?
EDIT (7/27/2018)
The information in the answer below may no longer be accurate. Your mileage may vary.
I sat down with an engineer and asked this exact question. This was their response:
Xcode 6 does not support building distributable Swift frameworks at this time and that Apple likely won't build this functionality into Xcode until its advantageous for them to do so. Right now, Frameworks are meant to be embedded in your app's project, rather than distributed. If you watch any of the session videos or see the sample projects, this is always the arrangement. Another reason is that Swift is very new and likely to change. Thus your Swift-based framework is not guaranteed to work on the platform you originally built it on.
Slight Update
The engineer mentioned that it's not impossible to make a framework for distribution, just that it's not supported.
I was able to get past the error by going to the target for the framework and on the Build Phases tab under Headers, remove the MyFramework.h file
However I was getting the "Underlying Objective-C module not found" error when I was using a framework to share code between a containing app and an app extension, both of which were pure Swift.
Assuming you are creating a truly pure Swift module, you must disable the Objective-C Compatibility Header and any generated interface headers so the compiler doesn't go off assuming it can find an Objective-C module for the framework.
Do Not remove your public framework header. You'll get a module-map warning at link time if you do.
You might find this useful: Creation of pure swift module
In short: it's possible to make static framework, but there is one issue: it doesn't work in end user' project if "ProjectName-Swift.h" header included.
But, it works fine if you use only swift.
I think it's a bug in XCode 6, or that Apple does not allow archiving the Framework from XCode while in beta.
If you compile to profile XCode generates the framework correctly. (See the Release folder created in DerivedData)
I'm trying compile the lastest WebRTC version for iPhone. I not need to compile the entire solution, I only need to compile the VAD module.
To do that, I have created a Xcode project and I have tried to compile the source necessary, but I have a problem with the *.s files and its assembler.
Like in the FFMPEG library, I know that I must "translate" the assembler code to an assembler code that the gcc for iPhone understand, but I don't know how I do this manually.
I have tried to create a configure file and set in it "as=gas-preprocessor.pl" (like in FFMPEG), but does not work.
Any idea? How do I run the gas-preprocessor.pl manually?
Thanks.
I'm just finishing it on iOS and has built standalone static libraries of NS/VAD/AECM and AGC, here's some tips for you, and hope you success:
1. Source File List
for standalone VAD build, you should make sure your project has all of these files(no .s file needed), and I'm not listed the header files here, you will get some header file can not be found errors, just fixing it and things will be done.)
webrtc_vad.c
vad_core.c
vad_filterbank.c
vad_gmm.c
vad_sp.c
real_fft.c
division_operations.c
complex_bit_reverse.c
cross_correlation.c
complex_fft.c
downsample_fast.c
vector_scaling_operations.c
get_scaling_square.c
energy.c
min_max_operations.c
spl_init.c
2. Adding a macro called WEBRTC_MAC
I'm not sure why the Xcode environment does not provide this macro, but it should be defined to ensure that WEBRTC_POSIX is enabled. To define this macro, adding it to a new header file or just define it in the webrtc-header-files.
3. Following these steps to build and setup a static library of WebRTC-VAD module on iOS
notice, do not use LLVM 2.0 to compile the VAD module(use GCC or LLVM GCC). cus' it can throw you lots of errors when compiling some webrtc variable declarations.
4. Using the libwebrtc_vad.a
if you got this far, things are easy to go, just include webrtc_vad.h and using the API provided by this module. and vad is working fine in my case.
hope i helped.
try to check this link https://groups.google.com/forum/?fromgroups=#!topic/discuss-webrtc/VJg-fk2-i_0 i believe you have to set inline assembly correctly. I am also onto this so let me know if you want to switch emails or something.
I have some source code in C/C++. I have to make static library to use in my iPhone application. is there any third party tool to create static library for armv6/armv7 ?
this link will help you create a static library in xcode ...
http://www.icodeblog.com/2011/04/07/creating-static-libraries-for-ios/
just rename the .m file to .mm file and write your c/c++ implementation code in it....
try it for a small function first and if it works for you can implement all your classes in it...
Please make sure when you try to use this library in any other project in XCODE , only use .mm extension for all your files even the appdelegate... hope this helps.
I would recommend iOS Universal Framework. I have used it to create a number of static frameworks that I link against my application projects. It works like a charm and is really easy to setup - no need to come up with your own complicated shell scripts.
It adds a template for a new target project type, which you can then import and use just like an ordinary Apple framework. I would recommend setting up a workspace containing both the framework project and application project, that way the dependencies are handled automatically by Xcode.
In general, you DO NOT WANT to link to a static lib that is made with another compiler than the one used to compile the lib. Static libs are not really portable between compilers, since static lib formats are not covered by C/C++ standards. Due to name mangling and other formatting differences, you may not be able to link at all, or worse, it seems to work but injects bugs. Worse, if you use the standard library from your compiler in your lib, it will create horrible name collisions when someone links to your lib and they don't use an IDENTICAL version of the standard library!
Publish the lib using the compiler you expect them to be using. And if you must use the standard library, then you have to make sure they have the same version you have. Really, you should just have them compile the lib themselves or prebuild it for each compiler you support. It sucks, but that's the reality of it as it stands today.
Each C/C++ library has some amount of headers that should be used with that library. And if you're use more than 1-2 libraries, custom header paths is kind of headache.
So I thought: is there a way to compile C libraries as frameworks. Static library + headers + versioning.
I found in XCode template for Cocoa framework but nothing about iPhone framework building. This simple step could allow developers to build and share between each other frameworks with some interesting code.
Also it would be great to use libpng, libjpeg and other libraries packaged as frameworks.
I won't use dynamic libraries in those frameworks. Only static version will be present.
I combined techniques I found here and here into my open source library here (NOTE - I have since removed the relevant scripts from this project. I have updated the link to point to the last revision that included these techniques.). Think that's basically the solution you're looking for.
Basically, it has a target that will build a fat static library (lipo builds for arm6, arm7 and i386). It has another target that takes that library and builds it into a framework.
There's no reason you can't use the same techniques for a C project. In fact I've started work on porting C the VTD XML parser to an Objective C framework using the same techniques.
Frameworks are basically just bundles of dynamic/shared libraries. Since this is not allowed in the App Store, you have to build static libraries and link them with your App's executable at compile time.
However, to ease the pain a little, you can have a Xcode project for each library and compile each library into a static lib. Another way would be to put all required source files into the main Xcode project and configure it appropriately so it all builds at once (I did this with small libraries like Minizip, for instance).
Hope that helps.
the problem you are trying to make already exists - it's called DLL hell
Best way is to stick with plain old static libraries when making small apps and organizing source/headers structure
I'm trying to write an SSH client for the iPhone, and I'd like to use the libssh2 open source library to do so. It's written in C.
How should I include this C library for my iPhone app? Should I compile it into some binary that I include into the my app, or do I add all the source to my project and try to compile it along with the rest of my app?
I'm interpretting this question as:
"Should I compile the C library code once, and include the binary library in my project? Or should I include all the source and compile it every time I build my app?"
It depends. One of the projects I work one depends on several external libraries. Basically, we have a simple rule:
Do you think you will need to change code in the C library often?
If you will be changing the code, or updating versions often, include the source and build it with the rest of your project.
If you're not going to change the code often or at all, it might make sense to just include the pre-built binary in your project.
Depending on the size of the library, you may want to set it up as a distinct target in your project, or for even more flexibility, as a sub-project of your main project.
If I was in your place, I would build libssh2 ahead of time and just include the binary library in my iPhone project. I would still keep the libssh2 source around, of course, in case it does need to be re-built down the road.
I have an iPhone app that is 90% c. I have had no problem adding 3rd party sources to my project and compiling. I am using Lua, zLib, and libpng with no modifications. I've also included standard libraries like unistd and libgen and they just workâ˘
The Three20 iPhone library has a great howto on adding their library to your xcode project. Give that a shot.
I think you will find in the long run you will be better off building it into a standalone library and linking it with your application. This makes it easier to integrate into future apps. Another benefit is that it encourages code separation. If you feel pretty confident with the library, you can link your debug exe to the release build of the library and get some extra performance.
I can't really think of any downsides to creating a library, after the initial cost of setting it up, and having an extra project to modify if you have some changes that need to be made to all your projects. Even if you don't know how to make a library for the iPhone, this is a good excuse to learn.
Just adding the source to you project should work fine as well.