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.
Related
I've seen that there are only tutorials of static linking SFML projects for Code Blocks and Visual Studio, but there isn't one for Dev C++. What I basically want is the executable to be independent, without having to execute it in the IDE. Anyone has any idea? Is it possible? I'm currently using Dev C++ 5.11 with the MinGW 64 bit compiler and the 2.4.2 version of SFML.
Dev-C++ as well as most other IDE (Code::Blocks, Qt Creator, etc.) just provide a GUI to configure flags which will then be passed on to an underlying compiler.
As such you can more or less follow the Code::Blocks tutorial and just map the different GUI fields to the ones available in Dev-C++.
Essentially, make sure to use the libraries with the -s suffix and to define SFML_STATIC.
Here's an example image I found, as I don't necessarily want to install Dev-C++:
On the right side under "Linker" you can add the SFML static libraries (e.g. -lsfml-graphics-s) and under "Preprocessor Definitions" at the bottom you can add SFML_STATIC
I am programming in Xcode in ObjC using a Cocoa static library built in c++ (built by me). For the library project, I made one public header(.hpp) that includes all the other header files(.hpp). Then in the ObjC project, I wrote a wrapper code(.hpp and .mm) to play as the interface, so it includes the public hpp header. To access the library, I then include the wrapper code in a normal m file. I believe all of these followed the tutorials, as it worked well for a few weeks.
However, after doing something stupid yesterday, the compiler for the ObjC project started to insist on building all the headers in ObjC. It first had problems with openCV packages in the c++ library, producing errors saying thoses are supposed to be built in c++ (as shown below). Even if I removed the openCV, the compiler cannot find any standard c++ libararies. I tried renaming the .hpp's to .h but it did not work.
Any suggestions on what I did wrong and how I can fix this?Much appreciated!
()
Your errors are coming from compiling ImageProcessor.m. .m is the extension Obj-C files, so the compiler will try to compile it, and everything it includes as Obj-C.
I'd suggest renaming it to ImageProcessor.mm.
After learning more about header files, I realized what I did wrong: I included every header in the interface, so they are re-built every time outside the library, even if they are referenced by none-c++ code. The solution is to separate the interface header with other headers in the library completely.
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.
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.
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.)