I am worried about the reliability of the MinGW compiler for 64-bit, as an alternative to the Visual C++ compiler.
For example, assuming C++ code builds and runs perfectly under Linux using GCC 4.6.2, will the corresponding MinGW produce similarly reliable executables/libraries under 64-bit Windows?
Is Cygwin a better option in terms of reliablity? Is neither to the Visual C++ compiler?
First, some misconceptions:
MinGW(.org) does not provide a 64-bit version of its runtime. MinGW-w64 does, in addition to their 32-bit CRT. They are also working on ARM support. And support various additional APIs (Win32 and others).
Cygwin <-> MinGW-w64: Cygwin does not use the MS CRT (msvcrt.dll). It instead inserts a POSIX compatibility layer in between your Cygwin app and the system's OS libraries (kernel32.dll, ntdll.dll, etc.), namely cygwin1.dll.
On to the question then...
I have found the MinGW-w64 compilers very good, and GCC 4.6 and above (actually, 4.5.1 and above) are very capable of producing good 64-bit code for Windows. Please remember that MinGW provides essentially the same C API as msvcrt.dll, so go to msdn.com for documentation (and be sure to look at the "MSVC++ 2003" version of documentation, some functions differ with the newer runtimes), do not think that because it's GCC, glibc documentation suddenly applies to Windows. Your code will have to be cross-platform. Also note that sizeof(long)!=sizeof(T*) on x64 Windows. A commonly encountered error when porting *nix or x86 Windows code to x64 Windows.
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.
Is there any C++11 compiler for Windows that supports the new C++11 type traits, like is_nothrow_move_constructible?
I was trying to write a container that supported it, only to find that none of my compilers (VC++ 2010, TDM MinGW32 GCC 4.6) support it...
For mingw, I would recommend STL's distro here (gcc 4.7.1). It comes with boost 1.50 also.
There also is mingw-w64 (a fork of the original mingw), I recommend rubenvb's personal builds here. Go to Toolchains targetting Win32 if you want the 32-bit versions. He also has personal builds of clang (clang support on windows is still very buggy. The x64 build will report linker errors so can only be used for better diagnostics, etc.)
STL's distro is very nice, however I find the mingw-w64 to have much better support for the win32 api (I have run into countless problems with the original mingw) and c++11 headers, such as <atomic> which is unsupported in the original mingw. mingw-w64 is much more actively developed (can create 32-bit and 64-bit binaries) and includes support for newer functions from windows vista and up.
For more info on the naming conventions of mingw-w64, see here and the faq.
Visual Studio C++ 2012 Beta supports a lot of C++11 type traits according to the reference. Have a look at the Visual Studio C++ 2012 Documentation However, I could not find is_nothrow_move_constructible documented there. It appears to be supported though.
GCC 4.7 does support is_nothrow_move_constructible you can try it on Windows by installing MinGW Distro.
Not an answer, but I just learned something from looking at the source code of GCC 4.7's type_traits header:
You don't even need is_nothrow_xyz in the first place!
The noexcept operator tells you if an exception throws.
So for these specific type traits, you can use that instead.
(Or at least in theory. Whether your compiler implements it is another matter.)
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.
Basically I want to compile C/C++ using the GCC on Windows. The two competing platforms, as i see it, are MinGW and Cygwin. Each have their own benifits and limitations. MinGW compiles for Windows, whereas Cygwin needs the cygwin .dll. However installing libraries on MinGW is difficult, whereas on cygwin it's easier, using the setup.exe as a 'package manager'.
My question is what's the best way to compile on Windows. Would it be better to use MinGW and struggle with libraries (in which case is there an easy way of installing libraries on MinGW). Or should I use Cygwin, if so how do I get it to compile without needing the cygwin .dll, effectively compile for normal Windows.
The easiest and best way to compile on windows is to use visual studio express. It is free. A good reason for using cygwin is for cross platform builds. A good reason to use gcc is it supports some compiler candy the Microsoft compiler doesn't.
But all in all VC++ Express is the way to go for windows only development.
There is always the option of using -mno-cygwin with Cygwin to compile against Windows libraries like MinGW does:
gcc -mno-cygwin file.c -o test
It's not an easy choice and mainly depends on how much you will rely on other libraries. Cygwin really adds an additional layer, which is heavier but "emulates" the Linux environment better than MinGW.
Edit:
Qt Creator allows you to compile with MinGW on Windows (and gcc on Linux, ...), has an IDE that makes debugging more friendly than gdb. If you need libraries, you still have the option of using the Qt libraries. That would be a good alternate solution to the Visual Studio if you really want to stick to gcc for future portability.
You might want to look at CodeBlocks. It is generally used to build WxWidgets apps, but it wraps MinGW nicely.
Actually, there's option #3: if your edition of Windows permits it, you can install Microsoft Services For Unix / Subsystem for Unix Applications, and then get gcc from SUACommunity. It has a package manager, too. Of those 3 options, this will give you behavior closest to a true Unix system.
However, the resulting applications aren't Win32 applications; they're SUA applications, and will require SUA to run. If you write code for yourself, it's usually not a problem if you write code for yourself, but if you want to write and distribute a proper Windows application, I would suggest staying away from anything that tries to emulate Unix, so MinGW it is.
Qt Creator comes with MinGW as standard and can be used to build projects that don't actually use the Qt framework.
There's an easy to install MinGW wrapped GCC at equation.com.
Click "Programming Tools" then "Fortran, C, C++", download the release you prefer, install and use.
One possible method is to use CMake which can build Visual Studio project from your sources and then compile from Visual Studio. It can build project for other IDEs too, so you can go cross platform.
I think the answer depends on whether you intend to use libraries or compile programs that are targeted to POSIX or a POSIX-based target. That's what Cygwin is intended for, while MinGW is more intended for compiling Windows-targeted programs using GCC.
Another option is TDM MinGW: http://www.tdragon.net/recentgcc/
It's basically an unofficial fork of MinGW with the latest GCC compiler available for both 32- and 64bit windows machines. Even some MinGW developers themselves use it.
Equation Gcc is even better: http://www.equation.com/servlet/equation.cmd?fa=fortran
I'm new to the VxWorks environment, I'm wondering what C and C++ compilers are available for use with VxWorks?
There are two: gcc and diab. They will be provided with your WindRiver platform (such as "General Purpose Platform 3.6"). The gcc is modified by WindRiver (and/or CodeSourcery) to work with VxWorks.
Now with VxWorks 6.9 there is a third option: Intel C++ compiler (for Intel target architectures only, 32 and 64 bit) -- diab will not target 64-bit
Greenhills development tools also supported the VXWorks environment in the past.
In addition to the customary Diab ("Wind River Compiler") and GNU, VxWorks 6.9 added Intel C Compiler (ICC), but ICC seems to have been dropped from version 7.
VxWorks version 7 adds LLVM/Clang.
As far as i know Tornado VxWorks IDE using gcc toolchain.
Any way i suggest to use the compiler provided by WindRiver (which i believe their version
of gcc) to avoid compatibility problems.
It's probably worth to menation the VxWorks version you having in mind.
I guess gcc version will be depend on VxWorks version and probably on target platform.