All of sudden yesterday C++ library and STL C++ library templates disappeared from my XCode 6.1 installation. Here is how it is supposed to look like:
And here is how it looks like now:
I uninstalled XCode completely and re-installed it but still those templates were missing. Is anyone else experiencing the same problem? How to fix it?
Never mind! The user interface to select project templates has changed a little bit in XCode 6.1 . Here is how to create a C++ library project:
To create a C++ library, select Library template (Even thought the description says: 'This template builds library that links against the Cocoa framework'. It can be a little confusing but you can change it to make it a C++ library in next step).
Click Next, and then you can choose the Framework Type to be Plain C++ Library, Cocoa, or STL (C++ Library). You can also specify Type to be Static or Dynamic.
I feel like an idiot now. I wasted at least couple of hours reinstalling XCode and trying some other things. I hope it saves someone else's time.
Related
Having some strange issues with a large iOS project I'm working on. I have tried to add a static library to the project and I get the following errors during linking:
XCode Error (Sorry I don't have enough reputation to post images inline!)
G4XSwiper is not the library I added however it seems to be causing the error.
The strange part is when I go into the build settings and change the C++ Standard Library from libc++ to libstdc++ it builds and runs fine. To be totally honest I'm not even sure what this setting means or does.
What could be the issue here? I've been pulling my hair out for two days on this. We have a lot of frameworks we depend on, is it likely we will run into problems by making this switch?
I have C++ code, which I have managed to compile into an iOS static library ("library.a") using Xcode. I am then including this in my project (Xamarin.iOS, though this shouldn't matter) and have managed to get it working as expected. The code is c/c++ and doesn't reference any code from the iOSFrameworks. I was wondering if it would be possible to find a way to build this (just compile the library) without a mac computer.
Something like download the clang compiler on a windows machine and then build an "library.a" that is compatible with the arm architectures and thus will work if I include it in my iOS project.
I have tried doing some reading on the web which suggests that it wouldn't work, but they might not be working in my exact circumstances etc.
The reason behind my need for this is because the C++ part of the code base is maintained by someone else, and we require them to build the iOS compatible library without us having access to their code. They do not have access to a Mac.
Thanks very much for any help.
I have written a DLL in VS2012 C++ and did not use anything fancy.
I think I have stayed cross-platform, at least I hope so.
Can somebody tell me how to most easily get it to compile to OSX code?
I think I will have to do some manual work, but I would like to find a pipeline that would allow me to easily upgrade my application both in VS2012 and in XCode without having to write down what I changed and then do the same changes in XCode.
Perhaps I can write one interface for Windows and one for XCode and simply leave the rest of the files as they are???
Thank you very much for the help.
You could:
Create a XCode project with the template: Cocoa Touch Static Library and add the code of the VS12 inside a folder Source.
Create an ObjC class to wrap your C++ code.
Compile the project like a static lib.
Add your static library with the correspond .h to your Xcode Project that will use the library.
Link the library with the dlyb used in your C++ code.
So you will have a VS solution and a XCode project for compile the library.
Here is a template with a UnitTest with simple C++ class and a ObjC Wrapper.
I need some help with wrapping C++ libraries in XCode.
What I want to achieve is to create new library in XCode, import C++ library (I have .a and .h files), wrap it to Obj-C so I can import that library to MonoTouch.
The reason why I do it round way is that when I try to import C++ lib into MonoTouch, because of name mangling I keep getting WrongEntryPoint exceptions. Correct me if I'm wrong but there is no way for me to find out mangled names, which depends on compiler.
Thank you in advance
Correct me if I'm wrong but there is no way for me to find out mangled names, which depends on compiler.
Technically you could. Many compilers share the same mangling syntax, maybe the most useful and long-lasting gift from Itanium ;-)
However it will bring it's own pain (e.g. non-primitive types, other compilers) and maintenance issues as you update your C++ code.
You'll better served by:
writing an ObjectiveC wrapper and use MonoTouch's btouch tool to generated bindings;
writing a C wrapper and using .NET p/invoke to call your code;
The choice it yours but if you think about reusing the C++/C# code elsewhere (e.g. Mono for Android) then using C and p/invoke will be reusable.
I would definitely recommend going the route of wrapping the library in an Obj-C library and using btouch to import the library into MonoTouch. I have recently done this for a C++ library that implemented a Sybase database engine. If you look at my questions you will find quite a few pertaining to wrapping C++ libraries as I posted a few times regarding issues I encountered.
Specifically, you can look at these questions:
Linking to a C++ native library in MonoTouch
Wrapping a C++ library in Objective-C is not hiding the C++ symbols
Application with static library runs on simulator but not on actual device
Undefined symbols when linking PhoneGap static library in MonoTouch
Linker options 'Link all assemblies" and "Link SDK assemblies only" causes undefined symbols in 3rd party static library
I would also recommend, if you are going to go the route of an Obj-C wrapper, that you get btouch to output code and include that in your project rather than including a dll from btouch. From my experience, the code worked more reliably than the dll, although the issues with the dll may have been resolved by now. But take a look at this question regarding the btouch issue:
Exception System.InvalidCastException when calling a method bound with btouch that returns an object. MonoTouch bug?
If you have specific questions/problems in building the Obj-C wrapper then ask them here and post some code and I am sure that I or other members of the community would be able to help you with it.
Bruce, as you assumed, I have problems with wrapping C++ code. After hours and hours of reading and trying, I couldn't wrap the C++ code.
Anyway, I managed to create a simple Obj-C library made of some dummy class, and then import it into another library. That worked fine. However, following same pattern, I included C++ .a file along with .h file (I'm not sure whether .h is mandatory because we can link header files in build options, right??) and when I compiled it, it went fine, the build succeeded, but XCode didn't produce new .a library.
I added linker flags: -ObjC -lNameOfLib
Does C++ Standard Library Type in Build - Linking has to be Static? And Symbols Hidden By Default as well?
It would be great if we could write step-by-step tut, since there are tons of various instructions, but I haven't been able to push it through the end.
I'm confused a bit..
Thank you guys...
I'll preface this by saying I'm a C# programmer who inherited horrible code with no documentation. I have an unmanaged C++ library wrapped with managed code that worked fine in VS2003 with .Net 1.1 Framework. I'm trying to get it upgraded to at least .Net 2.0.
I have the unmanaged C++ library that was compiled with "MSVC 8.x" (thus equivalent to VS 2005, I assume). I've been trying to migrate everything to VS2008 and still have some issues with this library at runtime.
My question is this: should this library work with VS2008? Or should I be developing in VS2005 if the library was compiled with VC8.x?
Any thoughts would be greatly appreciated. Thanks!
It should work, I expect that you are having issues with your marshalling. It is probably stuff that was declared incorrectly for PInvoking that managed to work in .NET 1.1 but not in later versions.
You don't say what sort of problems you are having at run time, nor do you state how you access your library. For example, do you compile your library along with your project? If so, can you turn on unmanaged debugging in your C# project and step into the code you are having trouble with? How are you calling the unmanaged code? Is it through PInvoke, or do you have managed C++ wrappers?
In my experience, the best solution for calling out to a legacy unmanaged library is to add a managed wrapper library for your legacy library written in managed C++. This way you present a managed interface for your library for all .NET languages to consume and you don't have to worry about getting your PInvoke signatures correct.
Your project should look something like this.
C# Application -> Manage C++ Wrapper DLL -> Legacy DLL
It can depend what else the lib relies on. For example, if you are using the STL across the library interfaces then it would be a bad idea to have the library compiled with a different version to the client. However, if the library presents a simple C style function interface then you shouldn't have problems.
If you have the source code for the library then I would recommend trying to port it to VS2008. In general it is much less hassle in the long run to have everything in the same development environment.
How are you wrapping the unmanaged lib ... presumably using managed extensions for C++ if it dates back to VS2003. This is now deprecated and has been replaced with C++/CLI as of VS2005. Whilst the newer compilers support a /clr:oldSyntax switch to still compile the old code there are definitely issues with it. We have old code that will not compile on VS2005(8) using this switch.
--Rob Prouse:
The wrapper uses managed C++, no PInvoke. The wrapper is compiled into a DLL that is then used by another application (as you illustrated).
The legacy code produces graphics objects. When I try to get the handle to an image, I get a null exception instead. The debugger doesn't let me get farther into the code to figure out why. Everything else seems to run ok - the other data objects needed to create the image exist and appear to be correct. (Sorry, I know that is still a pretty vague description.)
--Rob Walker:
I unfortunately do not have the source code.
Not sure about "using the STL across the library interfaces". Does graphics fall under that category?
I was able to get my application to run with using the /clr:oldSyntax switch, but that's where I get the null handles to images. I tried to put in all the modifications so that it would compile with /clr, but then I kept getting link errors that I couldn't resolve. (The linker kept complaining about not being able to find files even though those files were in the folder where it was looking.)