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.
Related
There is this library which is used as a reference by other programs: https://github.com/RetroAchievements/RASuite/tree/master/RA_Integration
I have downloaded the compiled programs (that come with the compiled library) and they work fine. My goal is to make a change in the library code, re-compile it and replace the DLL of the compiled programs I have downloaded with my own compiled DLL. Like so:
ProgramA.exe
|_ RA_Integration.dll < replace with my own (built)
Before even changing the code, I am just trying to compile the DLL and use it along the compiled programs I have downloaded. I am not willing to re-compile the programs themselves because it will be too much work because of dependencies etc. And I also would like to be able to just "ship" the DLL to whoever wants my fix.
So I have downloaded the source code of that library, re-compiled it myself successfully but when I use it instead of the one that comes with the programs, they do not start up (Windows Event Viewer say that there was a problem loading my DLL).
I am assuming that my system have differences with the system that built the original DLL and that it is the reason why it fails. My question is: can I find those differences? Although I am a professional .NET programmer (as in it's my job) I am a C++ newbie and I am having trouble to understand all those linker/precompiler/dependencies/c++ stuff that seem to give different builds/results from a machine to another.
All I have been able to find is that in the project properties the "Platform Toolset" is "Visual Studio 2013 - Windows XP (v120_xp)", therefore I have installed Visual Studio 2013 (with Update 5 since it seems Windows XP support was not present in base VS2013) but that seems to not be enough. I am running Windows 10, which was surely not the OS the original programmer used when they compiled the DLL a couple years ago, but not sure if that matters?
Is there anything that could be found from the DLL itself or from the project that would hint me as to what I need on my system?
Hope that makes sense.
Thanks
Before even changing the code, I am just trying to compile the DLL and use it along the compiled programs I have downloaded. I am not willing to re-compile the programs themselves because it will be too much work because of dependencies etc. And I also would like to be able to just "ship" the DLL to whoever wants my fix.
Here's your fallacy: your DLL is a linking dependency. You must re-build your application, because obviously, the ABI of the library changed, rendering it incompatible with what your program tries to call in functionality that it expects to be in the DLL.
There's no way around that short of building an ABI-compatible wrapper DLL using your precious programming knowledge :) Finding these differences is hard – because, you could for example export a symbol list from your DLL, which will basically contain all the functions that DLL "offers", but some aspects of how these functions need to be called aren't actually part of that and can only be deducted by a linker (or a skilled person with too much time on their hand and an unhealthy obsession for parsing things in their head) from the C++ source code.
In other words: you changed what you're run-time linking your program against. You must now rebuild your program. End of options!
So I made a c++ console game. Now I'd like to "release" the game. I want to only give the .exe file and not the code. How do i go about this. I'd like to make sure it will run on all windows devices.
I used the following headers-
iostream
windows.h
MMSystem.h
conio.h
fstream
ctime
string
string.h
*I used namespace std
*i used code::blocks 13.12 with mingw
& I used the following library-
libwinmm.a
Thank you in advance
EDIT
There are many different ways of installing applications. You could go with an installer like Inno or just go with a regular ZIP file. Some programs can even be standalone by packaging all resources within the executable, but this is not an easy option to my knowledge for C++.
I suppose the most basic way is to create different builds for different architectures with static libraries and then find any other DLLs specific to that architecture and bundle it together in one folder. Supporting x86/x86-64/ARM should be enough for most purposes. I do know that LLVM/Clang and GCC should have extensive support for many architectures, and if need be, you should be able to download the source code of the libraries you use and then compile them for each architecture you plan to support as well as the compilation options you need to compile to each one.
A virtual machine can also be helpful for this cross-compilation and compatibility testing.
tldr; Get all the libraries you need in either static or dynamic (DLL) format. Check that they are of the right architecture (x86 programs/code will not run on MIPS and vice versa). Get all your resources. Get a virtual machine, and then test your program on it. Keep testing until all the dependency problems go away.
Note: when I did this, I actually had some compatibility issues with, of all things, MinGW-w64. Just a note; you may need some DLLs from MinGW, or, if you're using Cygwin, of course you need the Cygwin DLL. I don't know much about MSVC, but I would assume that even they have DLLs needed on some level if you decide to support an outdated Windows OS.
I am developing a framework for other iOS developers and I am using boost as a dependency. I am creating a boost.framework which contains the libraries (fat library) for arm6, arm7, arm7s, arm64, i386 and x86_64. Compilation and linking seems to work fine, but using my library and the boost.framework in XCode 5.0.2 in a simulator results in the following error
Detected an attempt to call a symbol in system libraries that is not present on the iPhone:
pthread_cond_init$UNIX2003 called from function _ZN5boost18condition_variableC2Ev
However, deploying the App on a device does not yield any problems at all.
After looking around I found a StackOverflow entry explaining that his $UNIX2003 function names are part of the OSX library. Based on that I checked the linking of the library and only the i386 parts of the library are linked against the $UNIX2003 parts (which is in accordance to Apple's own description). The arm* architectures are using the unsuffixed versions.
My question is, what can I do to have it running on the simulator? Do I need to recompile boost with specific flags? Is there an option to tell the simulator to shut up? Or is there at least I way to tell the simulator to use the actual device libraries not the i386 ones?
There is the possibility of writing these $UNIX2003 functions myself which then delegate to the real ones. But since there are quite a few function calls I would rather not do that, especially since the developers using my framework would need to do the same I guess (which I would like to avoid).
After coming across a discussion on an unrelated mailing list, I found the original culprit: The boost library was built against the Mac OS X version of (I guess libc++), not against the iPhone simulator version of it. Fixing this generated the framework in the proper formats as well as containing only links to the proper versions of the system calls.
I am a C++ developer I am interested in Cocos2d-x framework. I know that you can write C++ code using the framework, compile it for different platforms and that's it, you have your 2D on Windows, Android, iOS. This is amazing but I don't understand how it is being done and, consequently, I worry that some thing that I have done for one platform will not work on other one. To go into details I would like to open my concerns. In order to do that let's clarify what is compiling and what is running a code.
What does it mean to compile C++ code for a platform (platform is OS + CPU architecture)? It means that C++ source code is mapped to instructions which is understandable for a concrete CPU architecture. And the final set of instructions is packaged into an executable file which is understandable for a concrete OS which means a concrete SO or OSes that understand how to handle the executable file can run it. Also we should not forget that in the set of instructions that the executable contains there could be system calls. Which is also specific to OS.
What does it mean to run the executable? It means that OS knows the format of particular executable file. When you give run command OS loades it into the virtual memory and starts to execute that CPU instructions set step by step. (Very raw but in general it is like that I guess.)
Now returning to the COSOS2D-X. How it is possible to compile a C++ code so that it was able to be recognized and loaded by different OSes and by different CPUs. What mechanisms we use in order to get appropriate .apk, .ipa or .exe files. Is there a trap that we can fall while using system calls or processor specific calls? In general how all this problems are solved? Please explain the process, for example, for Android or it would be great for iOS too. :)
Cocos2d-x has 95% of the same code for all target OS and platforms. And it has 5% of code which is written for the concrete platform. For example there are some Java sources for Android. And there are some Obj-C files for iOS. Also there is some code in C++ for different platform. #define is used to separate this code. Examples of such code is working with files which is written in C++ but differs from platform to platform.
Generating of appropriate output file is responsibility of the compiler and SDK used for target platform. For example xCode with clang compiler will generate the iOS build. While Android NDK with gcc inside will build the apk.
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.)