I need to distribute a closed-source library (in the form of a dynamic .framework) which uses C++ internally and exposes an Objective-C API at the module boundary. The library will be used by numerous clients in their apps.
As I understand, by default the C++ runtime is linked dynamically via libc++.dylib. So the question is: is the runtime compatible between iOS releases / compiler versions? Can my clients run into binary compatibility issues when using my library (e.g. OS is shipped with a different runtime version, producing subtle bugs in my library)?
Sidenote (as to where this question is coming from): On Windows, you would usually want to link the C++ runtime statically if you want to ensure that the binary works on all systems without the need to ship the specific version runtime component. So I wonder if the same problem existent on iOS.
Only Apple knows if or when some C++ library is no longer supported. My guess would be that apps depending on a no longer supported runtime would stop working completely or would not build with your library in the first place. I have found this info here (Xcode 10 (iOS 12) does not contain libstdc++6.0.9) indicating that, over the years, support for older runtimes may be dropped and then you'd need to build another library.
Speaking from past experience, we had an app - I know, not quite the same as a library - in the App store with a C++ core and Objective-C shim and did not care about C++ runtime compatibility. That never became an issue. Instead, from time to time (over several years and iOS iterations) there were slight user interface quirks that needed to be ironed out (I think with iOS7 - ok, you may not have an UI) then the forced move to 64-bit, then some API change where Apple wanted things that way or another... When there as an issue then we did a build with the latest XCode and that would have helped keeping things running, but the old version kept on working.
The upshot is, you'll need to be prepared to maintain your library and maybe something else 'gives' before the C++ runtime becomes a problem and then you'll just have to do another build for your customers.
If you are using libc++.dylib which is system wide library, then any application can also use it.
So by definition whoever delivers this library (Apple), is responsible for maintaining backward binary compatibility of this library.
If compatibility would have been broken, thousands of application would be corrupted.
On other hand if you are using some custom version of this library then it should be shipped with *.framework. In this case there is no risk of breaking compatibility since it is shipped with framework.
So basically there is no reason for you to worry about that.
If something is gets broken then lots of applications will be broken.
In the past new iOS versions have provided excellent compatibility with existing apps. If an app was built for an old iOS version, it would also run on new iOS versions. It seems that Apple simulates old iOS versions - including their visual style and quirks. If you run an app built for iOS 6 or earlier, it will still have the grayish look and not the new style introduced with iOS 7.
Once an app is updated, the story is different: you will need to use the latest Xcode, new rules apply and many old features will have been decommissioned. As part of this, Apple might remove APIs, switch to a new C++ compiler, change the standard C and C++ library etc.
So:
A released app in the App Store should continue to work for many years with your C++ library.
However, for the development of new apps or new version of an existing app, you will need to check the compatibility of your library regularly and possibly provide updated versions.
Related
I have watched a video in which one of the director of scs software (who makes a EURO TRUCK SIMULATOR game) saying that the game is written entirely in C++, yet the game runs on Windows and Mac OS as well. How could they achieve it? Is it possible to run a C++ program on MAC OS?
Yes.
...OK, stack overflow wants at least 30 characters. OS X comes with the C++ compiler clang++, which is built on top of llvm. In fact, Apple stopped supplying a port of gcc some time ago, so developers either have to build it themselves or adapt to clang. According to Wikipedia, Apple itself develops clang.
It is possible, either to run gcc in terminal or to use Xcode to compile it, however you cannot then use Cocoa but alternatives such as Qt are available for mac.
Sure, there are C++ compilers for Mac OS X as well. One is even included in xcode (the standard development environment on a Mac).
But that does not mean, that you can compile just any C++ program on a Mac. It has to be designed to use libraries, that are available on both platforms (instead of MFC on Windows or Cocoa on the Mac). This is possible for example by using wxwidgets or QT. With these two libraries it is even possible to compile the program for Unix platforms like Linux as well.
Regardless of language a multi-platform program relies on some basic support parts that are implemented differently on each platform. With pure standard C++ this is the standard library and the runtime support, but in practice a game, say, will also rely on 3rd party libraries with platform specific implementations. So given that the platform itself is compatible with the basic platform assumptions of the C++ language, and the Mac is, achieving such portability is conceptually very straightforward, although difficult to get perfect.
As an example of a platform that's not entirely compatible with C++, Microsoft's .NET virtual machine is apparently so at odds with the ideas of C++ that Microsoft has found it necessary to define two different non-standard variants of C++ for it, and offers no way to produce GUI programs for it in pure standard C++. It's not impossible to use only standard C++ for .NET, and indeed one main reason to use C++ with .NET is to combine standard C++ parts with more .NET-y parts; it's just that using only standard C++ the code becomes complex, inefficient and generally impractical. For example, my first questions here on SO concerned how to do a simple .NET message box in standard C++ by way of COM technology as an intermediate layer, and that worked, but with a ridiculous amount of complex non-general support code.
As another example, using C++ in web pages is very much an impedance mismatch, so to speak. Again Microsoft is the main player who has attempted this, with their ActiveX technology. It turned out to be a good way ensure that PCs all over the world got infested with malware, because C++ is not the kind of language where it's easy to constrain what the code can do. As far as I know only Microsoft's own Internet Explorer browser ever supported ActiveX in web pages. And as of Windows 10 the IE browser is being phased out and replaced by the newer Edge browser, that does not support ActiveX in web pages.
If I want my software to run on Red Hat Linux 6.0, do I have to build it on 6.0? Or can I build it on 6.3? (Similar question for 5.X) I'm asking a general question about runtime implications of shared libraries and similar "automatic" dependencies that get sucked in during the build process. And I'm interested only in the divergence between minor releases. I know that more things change between major releases. I'm interesting specifically in RH and RH-derived distributions. My program is written in C and C++. I think the biggest dependency I need to worry about is the GCC runtime libraries for C and C++. Is there a web page I can use to verify which GCC updates were used in which RH minor releases?
To be clear: I understand the goal and commitment to compatibility between update releases going forward. Upgrading from 6.1 to 6.2 should not break my existing applications. In order to build on a newer update and run on an older update, I would need the reverse kind of compatibility. I need 6.1 to be compatible with things built on 6.2. In general this kind of compatibility is impossible to achieve on a wide-spread basis, across all config files, libraries etc. But I only need a narrow slice of reverse compatibility.
I have an app that was designed, written and built successfully on 6.1. Now I want to build it on 6.2, but I want it to still run correctly on 6.1. Is there a general software release practice on Linux that you always have to build on the oldest update release that you want to support? Or do most people use trial-and-error to determine whether their app runs on older update releases? If you use trial-and-error, how much "error" shows up in the equation?
I have a project that requires writing a code for small executable file. I used visual C++ express 2010 IDE to create this file. After I finished writing the code, I tried to copy it to a couple of different PCs. It gives me an error message every time I clicking on this file to execute it. The message states that I have to install (.NET framework). I watched a couple videos on YouTube explaining how overcome this problem by changing the runtime library from multi-threaded Debug DLL (/MDd) to multi-threaded Debug (/Mtd). However; the IDE can’t debug the C++ code because when I create my project by using CLR template!
Is there any way to solve this problem? Can I create a similar program that not requires any further downloading once I using on different PC?
Is learning a different language like JAVA or C# will help creating small programs (like my program) that run on most Window platform machine?
Just use Qt - it runs on Windows, Linux, MacOS, support for Android and iOS is scheduled for this year, plus it supports embedded platforms and some of the more obscure mobile platforms. Also, support for Windows RT was just kickstarted. A complete library with tons of functionality, good documentation and lots of educational resources. It provides tons of tools, from implicitly shared containers through threading, signals and slots, 2D and 3D graphics, widgets, multimedia, sensors... and whatnot...
You can even develop commercial applications under the LGPL license.
Also comes with a pretty good IDE - Qt Creator.
You can develop standard C++ applications or use QML, which is a JavaScript like language for markup and scripting, which is used to build applications from C++ implemented components. You can also extend QML. It is much faster to develop with QML and you still get the advantages of platform native binary under the hood.
Note that you will still need to either ship a few DLLs with your application. Unless of course you use a static build, which requires you to either have your application open source, or purchase a commercial license... which doesn't come cheap...
But still, a few MB of DLLs are far better than the entire .NET framework. A static build will produce executables about 8-9 MB with no external dependencies.
Stick with the C++ standard, avoid Microsoft extensions (managed code), and call only POSIX functions of your OS, then you should be able to write portable programs.
You seem to have created a Managed C++ Project. Instead create an empty Win32 C++ project and then add in your .cpp/.h files. This will limit you to the default libraries available on all PCs with the C++ runtime. If you want to remove that dependency too then statically compile in the runtime using the /MT option. Details # http://msdn.microsoft.com/en-us/library/2kzt1wy3(v=vs.71).aspx
As you move ahead you would need to be conscious of what libraries you take dependencies on and what versions of the OS are those libraries available on or if you need to package them with your bits.
Both Java and C# will help making portable programs. Usually, people will have to install runtime environments for executables written in these two languages, however. These days, C++ is more portable than ever. You can easily run C++ executables in your browser:
https://github.com/kripken/emscripten
http://code.google.com/p/nativeclient/
This makes many of the reasons why Java and C# came about irrelevant.
Open standards like OpenGL also make portable GUI programming easier than ever. Try Qt, if you want to write a simple GUI in C++.
Note: It is possible to run C++ program in any computer without installing anything if you haven't use .NET framework. In your case, there can be two reasons to trigger error in target computer.
New computer doesn't have required run-time assembles.
New computer doesn't have required .NET framework installed.
..........................................
So what to do:
Before start your program you have to design weather are you going to use .NET framework support or not. If you use .NET framework when you develop your program, then you much install same or higher .NET framework in target computer.
If you no need to use .NET component then your target computer should only containing run-time assemblies.
How to get rid of .net framework
right click on the project in solution -> properties -> General -> Common language run time support -> select "No common language run time support".
..........................................
Then what you need is only relevant run-time assemblies be in target computer.
How can run-time assemblies be in new computer:
There are two ways:
Install suitable C++ disputable environment in target computer(if you use VS2008 SP1, C++ RD package should be this. Please consider the solution build architecture also (32 bit/64 bit) before download ).
Deploy run-time assemblies with your solution package. (I like this because user no need to install any third party components)
..........................................
How Deploy assemblies with my project:
for this your all DLL, LIB, EXE should use same run time version.(if not, you face troubling to redirect assemblies by 'manifest' files ).
How to check the run-time version.
open DLL,EXE by visual studio (open->file) -> expand RT_MANIFEST-> double click the file under it ->then assembly dependency details will open. -> copy the data in right column and paste to note pad.
You will see this kind of line there. and ther is the version run-time assemblies your specific DLL or EXE use.
assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86".....
After identifying the version of run-time assemblies follow this tutorial and try to run in fresh installed computer.
At last: If you think this bla.. bla.. is so complex and your program is very simple, then you can consider about "run time assemblies statically linking" (try Google). But personally I don't like this method.
good luck!
I am an experienced Mac/iOS developer, but I initially started to program in C++. I haven't touched C++ for years, and now, it's time to do so, because I want to have multi platform support for a new kind of file type I am trying to create.
C++ has evolved over the years, to what I find is a very bloated mess of 3rd party libraries and an effort by the C++ standards committee to control the evolution of the language. Hence, my questions.
I want to have as much advanced tools at my disposal as possible, and at the same time conform to standards as possible. My main development platform is OS X Lion, and I have access to a fedora 16 installation. I want to target Lion and above, Windows XP and above, and the latest Linux kernels, so backwards compatibility is not an issue here.
One choice is to install the Boost libraries to my machine, but to what I have experienced a long time ago it is a very painful process, with compile-time errors and quirks that have to be done to OS X. I don't know if that experience will be the same if I try that now. The other choice is to stick with TR1 which Lion currently offers. However, TR1 is not a standard as I understand, it is a de facto popular implementation of things that were scheduled to be done in C++11. That way I lose a lot of advanced features that Boost offers.
With these two options in hand, what is the recommended way to have advanced C++ features at your disposal and conform to standards as much as possible? If it's Boost, is it recommended to compile Boost as static libraries in order to avoid installing Boost on end-user machines?
What is the current support of Xcode 4.3 for C++11 features?
I would appreciate any comments on the above questions as well as any other thoughts on the matter. I am trying to get in sync with the current version and features of C++ and I begin to realize that this may not be so easy as I initially thought.
Thanks.
First of all, there are two very distinct parts in Boost:
those which are header-only
those which require compiled libraries
If you stick to header-only, it will definitely be much easier. Note that some libraries, like Asio, have two compilation modes (header-only and library). A number of useful libraries, however, such a boost::regex, do require a compiled library.
Second, C++11 support is moving fast. GCC 4.7 and the upcoming Clang 3.1 support all major features of the Standard, except from atomics (discussions are still ongoing on the best implementation strategies), so on Linux and Mac, things are great... however Visual Studio is lagging behind, and Microsoft is not really interested in moving fast, so on Windows support is minimal still (and advertised supported features are based on older versions of the Standard and not 100% compatible with the last version). It does not mean you cannot compile for Windows, merely that you should use Mingw or equivalent and thus forgo interaction with existing Windows DLLs.
Based on those two observations, I would recommend:
try to avoid C++11 for now if you want to interact with Windows DLL, otherwise I would recommend Clang (for its integration in XCode)
try to avoid Boost libraries and stick to the header-only parts (there is still much goodness)
if you want libraries, you can use DLL as long as you distribute them alongside the executable or use a package system or whatever, but it does present a greater difficulty (for the installation) than just static linking.
Note I'm not a Mac developer but I'd prefer Boost. Many C++11 standards are taken from it and you can expect more Boost features will be ported to C++ standards.
And as a Qt enthusiast: take a look at QtCore. It's very powerful and cross-platform.
Native exe!
that means my program can run easily without any requirement?
even if I use .net classes?
You know I want to write a program that is so light and I don't like to use C# or any other .net programing language because all of them need .net-framework 4.5.
Just think a 2.5 MB programm needs a +250 MB .netframework.
New Update - 12/01/2016:
It's almost 4 years ago when I asked this question. As you know Dotnet Native is announced. It's an interesting feature which compile IL into native code.
Compiling Apps with .NET Native
.NET Native is a precompilation technology for building and deploying
Windows apps that is included with Visual Studio 2015. It
automatically compiles the release version of apps that are written in
managed code (C# or Visual Basic) and that target the .NET Framework
and Windows 10 to native code. Typically, apps that target the .NET
Framework are compiled to intermediate language (IL). At run time, the
just-in-time (JIT) compiler translates the IL to native code. In
contrast, .NET Native compiles Windows apps directly to native code.
For developers, this means:
Your apps will provide the superior performance of native code.
You can continue to program in C# or Visual Basic.
You can continue to take advantage of the resources provided by the .NET Framework, including its class library, automatic memory
management and garbage collection, and exception handling.
Last I checked none of the .NET frameworks were 250+ MB! Yes, the offline installer for .NET Framework 3.5 SP1 is 231MB but it contains x86 and x64 versions of .NET 2, 3 and 3.5 sp1.
You should read this http://www.smallestdotnet.com for details on sizes of various versions of the installers.
Now on to your question:
Yes, It is a little annoying to have your clients install a big framework, even 20-40MB does get annoying. With .NET, the advantage is the ease of programming (In my opionion) compared to other Native options.
Your native options are:
MFC - You need only the VS runtimes installed, which is 1-2MB and is usually installed on newer pcs. Also, you can ship your application with the MFC libraries packaged into a dll which is again <2MB
The trade of here is you need to program in C++, the libraries overall are a very thin layer over the native libraries. and people have had harsh opinions about MFC. I've barely just tried it.
Win32 API - This is going all bare bones, and quite difficult, you could use C or C++ but you'd really have to know a lot about the Win32 API and how windows itself works (Stuff like windows messages, hwnds etc) Its not fun, believe me. But during deployment you would not need any external libraries.
There are tons more options, see here:
Native Windows Application Development Options
https://stackoverflow.com/questions/2711599/what-programming-language-should-i-use-to-create-small-native-windows-applicatio
Here are some links on MFC that might help:
Want to learn Windows Programming,some suggestions?
How do I decide whether to use ATL, MFC, Win32 or CLR for a new C++ project?
C++ MFC vs .NET?
https://stackoverflow.com/questions/557114/stick-with-mfc-or-go-to-net
you are able to create native exe by using c++ Win 32 projects.
Alas, nearly everything requires a download runtime library and even if you have one installed, you'll need to download updates for them almost continually. Even Microsoft C++ apps nowadays come with security updates that have to be installed if you've compiled your app with them.
But.. there is a solution of sorts. If you use C++, it has a feature where only the things you use are compiled into the final app. Normally, this would require linking with all the library dlls, but if you statically link with the library, you will end up with a single .exe that is as small as can be, and you will not need any dlls (as all the code contained in the library will be compiled into the .exe).
The benefits are debatable compared to dlls, but as MS has pretty much broken the idea of shared dlls in .NET (ie, you practically have to put all the shared dlls in the same directory as your running app, giving you a nightmare in maintenance if you have these shared dlls spread around all your apps) then there's not much of a difference anymore. Static linking is getting a little bit of a comeback and sounds like its what you want.
For modern C++ development, you'll probably want to take a look at Qt instead of MFC. Its a lot nicer to use and is cross-platform so you can run Qt apps on your Android or Linux platforms as well as Windows.