I am new to C++ and I am now struggling with compiling and linking.
Recently I have been using cmake and make to recompile a library (mlpack) that makes usage of Boost (Cmake does not find boost 1.51 (windows 8)).
In a first attempt, I downloaded precompiled binaries for windows. This did not work out well and I have been explained the binaries I was using were for MSVC, not MinGW, therefore troubles. And indeed, after recompiling boost using MinGW, things went ok.
Here I would just like to get an intuition what would be the differences between binaries for MSVC and MinGW. I (naively?) thought binaries were specific to OS/processor. What do the binaries for MSVC contains that make them unusable by MinGW ?
It is relatively easy to combine artifacts (static/shared libraries) produced by MSVC and MinGW (this applies to other C compilers in general) as long as they export pure C API. This makes C API to be very portable and that's one of the main reasons why so many popular libraries still prefer to use pure C API.
The story with C++ is completely different. The most notorious obstacles for proper interoperability between artifacts produced by different C++ compilers are differences in name mangling and application binary interface (ABI). This applies to all C++ compilers in general, and not only MinGW and MSVC. If you want to learn more about interoperability pitfalls between MSVC and MinGW in particular, I encourage you to read the following articles:
Interoperability of Libraries Created by Different Compiler Brands
Binary-compatible C++ Interfaces
To be simple.
Windows speaks French.
MinGW speaks French, German and English.
Unix systems speak German.
The MSVC binaries are written in French.
The MinGW binaries are written in FrenchAngloGerman.
The UNIX binaries are written in German.
Windows needs MinGW to translate some of the German and English to French before it can understand everything.
MinGW is not like the other programs. It is basically a mini OS between Windows and Linux. So mostly it needs a modified form of binaries to work properly. The fact that you develop your program on Windows on MinGW doesn't mean they will run on pure Windows with out any problems. You still need to ship or distribute the MinGW libraries and executables that you used with your program.
Related
Could anyone shed some light on C++ library versioning and distribution of
GCC library (libgcc, libstdc++,..?)
Microsoft Visual C++ runtime libraries (6.0, 2005, 2008, 2010, 2012, 2013, 2015,....)
With my limited exposure to GCC programming, I have never seen C++ runtime libraries being distributed along with program. That is often the case with MS Windows programs.
Can a relatively old linux system run a newer C++14 program (which is compiled on a newer system and then copied over to old system)?
Do GCC programmers distribute runtime libraries along with programs? If no, Why do Windows programs distribute them? How GCC distributions ensure that a C++ program always works when installed?
What about the frameworks such as Qt, How does Qt handle versioning and distribution on Linux and Windows? Does Qt also distribute runtimes for different versions?
May be it has to do with platform, how Linux is designed vs How Windows is designed.
What is so fundamentally different in approaches GCC & MS Windows take?
GCC's runtime libraries, like GNU's C library, provide a stable binary interface (small footnote: GCC 5.1 kind of blew this up, due to new C++ features that had to be implemented).
Microsoft's libraries don't, and each little version difference may and probably will break the ABI (application binary interface).
Additionally, Microsoft compilers change their ABI with version increments as well, making it a bad idea to combine code built by different versions of their tools. Also here, GCC maintains a strict ABI, which makes object code perfectly compatible (if no ABI breaking codegen options are given of course).
This ABI consists of object size and layout, which a compiler uses when generating code. Therefore running code built against one version but using a different version at runtime may produce unexpected results because the memory layout and use is just different.
GNU/Linux is quite strong in this regard, and is generally able to maintain strong backwards compatibility.
As long as the compiled program was compiled against an older version of the library, it will run perfectly if loaded with a newer version that a user has installed.
The same story goes for Qt, which only breaks ABI between major version numbers (Qt 4 and Qt 5 cannot be loaded at runtime interchangeable).
There are some small exceptions, GCC 5's libstdc++ being a big problem there. I know of no big glibc ABI breakages though.
The new Microsoft Universal CRT attempts to solve this issue, by providing a stable C runtime interface and as the story would have us believe, provide a glibc style library ABI stability. This UCRT is available for Windows Vista and up, but applications need to be compiled specifically against this. The first version of VS that has this capability, is VS2015.
I have a C++ eclipse project that I would like to easily compile In Windows and OSX.
The project is currently using an automatically generated makefile.
The libraries that I need vary depending on the platform.
In osx I'm using the CoreMidi, CoreAudio, and CoreFoundation frameworks.
In Windows I'm using the winmm.lib and multithreaded libraries.
What's the simplest way to link different libraries/frameworks depending on the current platform?
I'm currently using the gcc toolchain on OSX. Should I start using the cross compile toolchain?
Should I have two projects. One for working in windows, and one for osx, checking them both in to version control?
Should I write a custom makefile instead of using the automatically generated option that has different g++ arguments depending on the platform?
I personally had the same goal for a project and came to the conclusion the Qt framework was the best thing for me. It handles multiple languages, unicode strings, XML, network communications, native looking user interfaces, console applications: it can do an AWFUL lot.
However, as Paul pointed out, you really have to plan it from the start.
Qt does a good job of abstracting the platform away (in a module called QtCore) allowing you to write vanilla C++ code, or you can chose to include some Qt C++ language extensions which a Qt helper application called the moc (meta object compiler) creates vanilla C++ from, which can then be compiled by most common C++ compilers.
It also has a nifty cross-platform makefile generator called qmake which works on project files to create normal make files for the platform its running on.
Off the top of my head at least Windows XP & 7, OSX 10.4, 10.5, 10.6 are supported currently. But note that OSX Lion is (as of writing) not officially supported but I suspect it will be in the next release.
Based on your description, I am not sure you can easily make it cross-platform. Even without using third-party library, you have to provide separate code for osx and windows. Most of time, they design the system as cross-platform first. It's really hard to make an existing project on single-platform to cross-one. If you have the cross-platform requirement, you'd better design in that way first and rewrite from scratch.
Even though Eclipse can run fine on both OS X and Windows, it is not designed to be used in this way.
The best way to do it is to use separate IDE projects for each platform. This this is the easiest way to have unique compilation settings for multiple platforms.
Yes, you can use two eclipse projects. Alternatively, it's not unusual to have a X-Code project for OSX, and a Visual Studio Project for MS Windows.
I want to build cross-platform statically linked library in C++.
How am I supposed to do this(I am a complete NOOB, never been using g++,gcc,mingw etc I looked on the internet for a solution to my problem, but didn't find anything. Except that mingw is a Minimalist GNU for Windows...)? I've been always using Visual c++ on windows, but now I have to build lib which will be attached to Qt projects for: windows,mac,linux.
If anyone know a good tutorial, on using compilers, and how to build libraries, I'll appreciate sharing them here :)
Thanks, may the force be with you.
MinGW is a very good compiler! I use it all the time. Even though MinGW stands for Minimalist GNU for Windows, MinGW has everything you need to program in either C++ or C. If you are creating a QT Application, I recommend using QT Creator (just google it). I haven't used it lately, but I think it supports Cross-Platform compiling (as does MinGW, with some command-line commands...).
The best way to cross-compile though, is but getting a copy of each OS that you are going to compile for. So if you are doing Windows, Mac, and Linux, I recommend getting one of each (Mac OS X is around $25 and Linux is free). Then just use the included compilers (XCode on Mac; GCC on Linux) to compile. Unfortunately when you are performing cross compiling, you need to support each OS individually (some parts can shared between OSes).
Since you will be using a toolkit (QT), you probably don't have to worry much about platform specific calls or anything. Just make sure you use the QT typedefs and structs and not the Microsoft Windows ones...
I have some question about cygwin :
Can I use Cygwin develop socket based code?
Does Cygwin have read() and write() functions that work with file descriptors?
Can I use Pthread library in Cygwin?
Does code that compiles in Cygwin also
compile in Linux without any change or with little change?
Will an executable file that built by
Cygwin run in Linux ?
Why does Cygwin not need the linker
option -lpthread when I use pthread library?
why in #include <iostream> don't I need to use using namespace std; ?
Can I work with QT in Cygwin? If so,How?
Can I boot my Linux in other
partition with Cygwin and use it?
Can I access the other partition
that is EXT3 in Cygwin?
On 1:
Yes. Socket libraries are shipped with Cygwin - many socket based apps such as web servers are included in the base distribution.
On 2:
Yes. I think all of the 'section 2 and 3' system calls in the GNU C runtime and library are implemented by the cygwin runtume. You can check this in the man pages that come with Cygwin. A list of system calls and std lib calls implementd by Cygwin can be found here.
On 3: Yes. Pthread is included in Cygwin. The list referred to in the link above mentions pthreads as well.
On 4: Anything built against GNU libraries should work with little or no change between Cygwin and Linux (assuming there are no dependencies missing on Cygwin). Depending on CPU architecture you may have to worry about word alignment, endianness and other architecture-specific porting issues, but if you're targeting Windows and Linux on Intel your code would have few if any porting issues arising from CPU architecture.
On 5: Cygwin will build a program against its own shared libraries by default but GCC can cross-compile to target other platforms. You could (in theory) set GCC up to cross-compile to any target supported by the compiler. There are plenty of resources on the web about cross-compiling with GCC, and I don't think the process will be materially different on Cygwin.
Note that Cygwin binaries will not run on Linux - or Vice-versa. You will still need separate builds for both.
On 6: Not sure - at a guess it's included in the standard runtime, perhaps because it was necessary to wrap the Win32 threading API for some reason.
On 7: Don't know - it's probably the same on g++ on all platforms. Apparently a compiler bug. Dan Moulding's Answer covers this in more detail.
On 8: Yes. IIRC QT is available in the standard builds and it will certainly compile on Cygwin. As with Linux/Unix, QT on Cygwin uses an X11 backend so you will need to have an X server such as XMing running.
In order to avoid the dependency on an X server you may want to build QT apps against the Win32 API,. It is possible to do this with MinGW, which is a set of header files and libraries to build native Win32 apps with GCC. MinGW can be used from within a Cygwin environment (an example of GCC on Cygwin cross-compiling to a non-Cygwin target) and the installer from cygwin.com gives you the option of installing it.
MinGW is quite mature; it has all of the 'usual suspects' - libraries and header files you would expect to find on a Unix/Linux GCC development environment and is very stable. It
is often the tool of choice for building Win32 ports of open-source software because it is (a) free, (b) supports the libraries used by the software and (c) uses GCC so it is not affected by dialectic variations between MSVC and GCC.
However, these dialectic variations in the language and available libraries (for example MSVC doesn't come with an implementation of getopt) mean that porting programs between MinGW and MSVC can be quite fiddly. My experience - admittedly not terribly extensive as I've only done this a few times - is that porting applications between MinGW32 and Linux is easier than porting between MinGW and MSVC. Obviously apps with non-portable dependencies such as Win32 specific API usage would require the dependent components to be re-written for the new platform but you'll have far fewer problems with differences in the standard libs, header files and language dialect.
QT does a fairly good job of providing a platform abstraction layer. It provides APIs for database access, threading, I/O and many other services as well as the GUI. Using the QT APIs where possible should help with portability and the Unix/Linux flavoured libraries that come with MinGW mean that it might give you a good platform for making applications that will port between Win32 and Linux with relatively little platform dependent code.
EDIT: The qt development packages in Cygwin are:
qt4: Qt application framework (source)
qt4-devel-tools: Qt4 Assistant, Designer, and Linguist
qt4-doc: Qt4 API documentation
qt4-qtconfig: Qt4 desktop configuration app
qt4-qtdemo: Qt4 demos and examples
You'll probably also need gcc4-g++ and some other bits and pieces. This listing on the cygwin web site has a list of the packages.
"Yes" to all of those except 5. You'll have to build your executables separately for Linux, but that should be straightforward since the answer to 4 is "yes".
Make sure you install all the development headers you need on both platforms.
Yes, Yes, Yes, Yes (if you write it carefully and don't use anything specific to cygwin), No.
On 5: it may be possible to cross-compile from Cygwin to Linux, I really don't know. If it is, then technically some executables "built by Cygwin" would run on Linux. But Cygwin executables won't run on Linux.
1-4: The answers to these are all "yes", because all of these features you are asking about are part of the POSIX standard. Cygwin is basically a POSIX layer for Windows so, naturally, Cygwin includes all of these features.
5: No, Cygwin binaries will not execute under the Linux kernel, because ultimately the code generated by Cygwin is Windows native code. It will link with the usual Windows DLLs (like kernel32.dll), whereas Linux does not even have a notion of DLLs (it has shared objects which are similar, but different). More importantly, executables built under Cygwin will be in the PE format, but Linux generally uses the ELF format for executables. You could, of course, do cross-compiling under Cygwin, and thereby generate native Linux executables, but it doesn't sound like this is what you are looking for. Also, compiling a new version of GCC to use as a cross-compiler under Cygwin is probably no trivial task.
6: GCC under Cygwin doesn't require use of -lpthread because all of the pthread code under Cygwin is in cygwin1.dll which is always linked in by default.
7: This is a bug in GCC (on all platforms). It has been around for a long time and will probably never be fixed.
8: ConcernedOfTunbridgeWells did a great job of explaining this, so there's not much left for me to say. However, it's worth noting that Cygwin has the X.org X Window System in its package list. With Cygwin 1.7.x, setting it up and using it is a breeze and it seems pretty rock-solid. If you want to use Qt with X, I'd recommend using Cygwin's X server.
In response to #7, the version of the C++ compiler that you have is probably out of date. If you don't need linux/posix portability, I'd switch to the non-cygwin MinGW GCC compiler - you can get 4.4.1 at http://tdragon.net/recentgcc/
Regarding 6, you don't need -lpthread because Pthreads support is part of the Cygwin DLL.
I have the source code for some very simple command line programs. I was considering the option of compiling them on a Linux machine (they were deveoped here) so they can be used on Windows. If I am not wrong this is called Cross-compiling. I have never tried it, but reading yesterday some information, it seems to be kind of complicated or not successful. I would like to hear about your opinions, and how could I port a simple "hello world" program, which compiles on Linux with g++.
Thanks
Look into mingw, a suite of tools for building Win32 applications in Linux. If the programs don't depend on any Linux-specific functionality not supported by mingw, you should be fine.
Note that cross-compilation is not the same thing as cross-platform. With cross compilation, you compile the code to a Windows executable on the Linux box, then transfer the executable to a Windows box. With cross-platform, you transfer the source code to the Windows box and compile to a Windows executable using a Windows compiler.
The former is quite difficult (but not impossible), the latter is very easy, using a compiler such as MinGW, a others have mentioned.
I cross-compile on a daily basis. But I don't set up cross-compilers on a daily basis. It can be tricky, but it's certainly possible.
As long as you use standard C++ your code will be cross-platform. You can also use cross-platform libraries like STL, boost, Poco, Qt, etc...
Only when you start to use platform specific code you lose portability. For example including <windows.h> will make your code only compilable on Windows. (There are techniques around this like the #ifdef macro. This enables certain code portions only on one platform.)
So a simple hello world program should work on Linux, Mac, Windows or any other platform. You don't need anything special for this.
Note:
Some may mention Cygwin or mingw32. I'll briefly explain what they are:
Cygwin allows you to compile Linux applications using gcc/g++ on a Windows machine.
Mingw32 allows you to compile Windows applications using gcc/g++ on a Windows machine.
Edit:
If you want to setup a system for cross-compilation, then I recommend that you have a look at cmake.
Yes. We are currently compiling a 250 kloc app, running Qt with daily builds. It's working prefectly everyday, although I've to admit it is not distributed outside the company, but only used internal. For official releases, Visual Studio is prefered.
Compiled using mingw standard packages on Debian.