I'm an avid Python user and it seems that I require MinGW to be installed on my Windows machine to compile some libraries. I'm a little confused about MinGW and GCC. Here's my question (from a real dummy point of view):
So Python is language which both interpreted and compiled. There are Linux and Windows implementations of Python which one simply installs and used the binary to a execute his code. They come bundled with a bunch of built-in libraries that you can use. It's the same with Ruby from what I've read.
Now, I've done a tiny bit a of C and I know that one has a to compile it. It has its built-in libraries which seem to be called header files which you can use. Now, back in the school day's, C, was writing code in a vi-like IDE called Turbo-C and then hitting F9 to compile it. That's pretty much where my C education ends.
What is MinGW and what is GCC? I've been mainly working on Windows systems and have even recently begun using Cygwin. Aren't they the same?
A simple explanation hitting these areas would be helpful.
(My apologies if this post sounds silly/stupid. I thought I'd ask here. Ignoring these core bits never made anyone a better programmer.)
Thanks everyone.
MinGW is a complete GCC toolchain (including half a dozen frontends, such as C, C++, Ada, Go, and whatnot) for the Windows platform which compiles for and links to the Windows OS component C Runtime Library in msvcrt.dll. Rather it tries to be minimal (hence the name).
This means, unlike Cygwin, MinGW does not attempt to offer a complete POSIX layer on top of Windows, but on the other hand it does not require you to link with a special compatibility library.
It therefore also does not have any GPL-license implications for the programs you write (notable exception: profiling libraries, but you will not normally distribute those so that does not matter).
The newer MinGW-w64 comes with a roughly 99% complete Windows API binding (excluding ATL and such) including x64 support and experimental ARM implementations. You may occasionally find some exotic constant undefined, but for what 99% of the people use 99% of the time, it just works perfectly well.
You can also use the bigger part of what's in POSIX, as long as it is implemented in some form under Windows. The one major POSIX thing that does not work with MinGW is fork, simply because there is no such thing under Windows (Cygwin goes through a lot of pain to implement it).
There are a few other minor things, but all in all, most things kind of work anyway.
So, in a very very simplified sentence: MinGW(-w64) is a "no-frills compiler thingie" that lets you write native binary executables for Windows, not only in C and C++, but also other languages.
To compile C program you need a C implementation for your specific computer.
C implementations consist, basically, of a compiler (its preprocesser and headers) and a library (the ready-made executable code).
On a computer with Windows installed, the library that contains most ready-made executable code is not compatible with gcc compiler ... so to use this compiler in Windows you need a different library: that's where MinGW enters. MinGW provides, among other things, the library(ies) needed for making a C implementation together with gcc.
The Windows library and MSVC together make a different implementation.
MinGW is a suite of development tools that contains GCC (among others), and GCC is a C compiler within that suite.
MinGW is an implementation of most of the GNU building utilities, like gcc and make on windows, while gcc is only the compiler. Cygwin is a lot bigger and sophisticated package, wich installs a lot more than MinGW.
The only reason for existence of MinGW is to provide linux-like environment for developers not capable of using native windows tools. It is inferior in almost every respect to Microsoft tooolchains on Win32/Win64 platforms, BUT it provides environment where linux developer does not have to learn anything new AND he/she can compile linux code almost without modifications. It is a questionable approach , but many people find that convenience more important than other aspects of the development .
It has nothing to do with C or C++ as was indicated in earlier answers, it has everything to do with the environment developer wants. Argument about GNU toolchains on windows and its nessessety, is just that - an argument
GCC - unix/linux compiler,
MinGW - approximation of GCC on Windows environment,
Microsoft compiler and Intel compiler - more of the same as names suggest(both produce much , much better programs on Windows then MinGW, btw)
Related
I have been doing a lot reading lately about how glibc functions wrap system calls in linux. I am wondering however about the relationship between glibc and the GNU C Compiler.
Lets say for example I wanted to write my own C Standard implementation and write a new library called "newglibc" and I change things just slightly. Like for example I take more checks and actions before and after the system calls. Would I have to write a new compiler? Or would I be able to use the same GNU gcc compiler?
If the compiler is completely separate from the library, then would someone be able to, THEORETICALLY, use the gcc on windows system if they could turn it into a .exe and provide the standard C library that windows provides?
Thank you
The Linux kernel, the GNU C Library ("glibc"), and the GNU Compiler Collection (gcc) are three separate development projects. They are often used all together, but they don't have to be. The ones with "GNU" in their name are offically part of the GNU Project; Linux isn't.
The C standard does not make a distinction between the "compiler" and the "library"; it's all one "implementation" to the committee. It is largely a historical accident that GCC is a separate development project from glibc—but a motivated one: back in the day, each commercial Unix variant shipped with its own C library and compiler, and they were terrible, 90% bugs by volume was typical. GNU got its start providing a less terrible replacement for the compiler (and the shell utilities, which were also terrible).
Replacing the compiler on a traditional commercial Unix is a lot easier than replacing the C library, because the C library isn't just the functions defined in clause 7 of the C standard; as you have noticed, it also provides the lowest-level interface to the kernel, and often that wasn't very well documented. glibc did at one time at least sort-of support a bunch of these Unixes, but nowadays it can only be used with Linux and an experimental kernel called the Hurd. By contrast, GCC supports dozens of different CPUs and kernels, and Linux supports dozens of different CPUs.
If you write your own C library and/or kernel, it is relatively easy to write a "back end" so that GCC can generate code for them as a cross-compiler, and somewhat more difficult to port GCC to run in that environment. You may also need to write a back end for the assembler and linker, which are yet a fourth project ("GNU Binutils"). Porting glibc to a new CPU running Linux is a large but straightforward task; porting glibc to a new operating system is hard, especially if that OS is not Unix-ish. (Windows is decidedly not Unix-ish, so much so that when Microsoft wanted to make it easier to run programs written for Unix under Windows, the path of least resistance was to bolt an in-house clone of the Linux kernel onto the side of the NT kernel. I am not making this up.)
If you write your own C compiler, you will have to make it conform to the expectations of the library and kernel that it is generating code for. A lot of that is documented in the "ABI" specification for the environment you're working in, but not all, unfortunately.
If that doesn't clarify, please let us know what is still unclear.
It seems I've got a real problem here due to my lack of any knowledge about Linux systems:
I have downloaded some open source code, which
is written in C
uses complex.h, so I assume it is ANSI C99
comes with makefiles designed for compilation under Linux systems
provides interfaces to IDL, MATLAB, Python etc.
I am indeed familiar about compiling C/MEX files under Windows-based MATLAB environments, but in this case I don't even know where to start. The project is distributed in several folders and consists of dozens of source and header files. And, to begin with, the Visual Studio 2010 compiler I've used to compile MEX files until now does not comply with the C99 standard, i.e. it does not recognize the complex.h header.
Any help towards getting this project compiled would be highly appreciated. In particular, I have the following questions:
1) Is there any possibility to automatically extract compilation information from the MEX files and transfer it to Windows reality?
2) Is there any free compiler being able to compile C99 stuff, which is also easy to embed in MATLAB?
I have done this (moved in-house legacy code inc. mex files to Win64). I can't recommend the experience.
You will have to recompile, no way around it.
Supported compilers for mex depend on your MATLAB version
This File Exchange entry for using Pelles C may be a starting point (if it works with your version of MATLAB).
I am guessing that there is a main makefile which then works through the makefiles in the subdirectories - have a read through the instructions for compiling under Linux, it will give you some idea of what's going on and may also discuss what to do if you want to change compiler. Once you've found a compatible compiler, the next stage is to understand what the makefiles are doing and edit them accordingly (change paths, compiler, compiler flags, etc.)
Then, from memory (it was a while ago), you get to enjoy a magical mystery tour through increasingly obscure compiler errors. Document everything because if you do get it working, you won't be in a mood to do this twice.
MATLAB R2016b on Windows now supports the MinGW compiler. I'm successfully using this to compile code written primarily for Linux/gcc. I installed this from the Add-On menu in MATLAB (search MinGW).
For my case, I'm building with the legacy code tool. The only thing I needed to do differently than normal was to tell the compiler to support c99 via a compiler flag. This does the trick:
legacy_code('compile', def, {'CFLAGS=-std=c99'})
I had trouble getting the flag command just right (I had some extra quotes that apparently broke things), and asked The MathWorks, so credit is due to their support team for this.
If you are using mex, I would expect to do something very similar.
I would guess that the makefiles are irrelevant for your application; you will need to tell the mex or legacy_code function about all of the files necessary to build the whole application or link against pre-built libraries (which it sounds like you don't have).
I hope this helps!
I wanted to know what is the current standard C compiler being used by companies. I know of the following compilers and don't understand which one to use for learning purposes.
Turbo C
Borland C
GCC
DJGPP
I am learning C right now and referring to the K&R book.
Can anyone please guide me to which compiler to use?
GCC would be the standard, best supported and fastest open source compiler used by most (sane) people.
GCC is going to have the best support of the choices you've listed for the simple reason that it comes standard in GNU and is the target of Linux. It's very unlikely any organization would use the other three beyond possibly supporting some horrible legacy application.
Other C compilers you might look into include:
Clang: an up-and-comer, particularly for BSD and Mac OS X
Visual Studio Express: for Windows programming
Intel Compiler Suite: very high performance; costs money
Portland Group: another high-performance commercial compiler; used typically for supercomputers
PathScale: yet another commercial high-performance compiler
If you are starting to learn the language, Clang's much better diagnostics will help you.
To make your (job) applications tools section look better, GCC (and maybe Visual Studio) are good to have knowledge of.
GCC (which I use in those rare moments when I use C) or ICC (Intel C Compiler), though ICC is known for making code that runs slowly on AMD processors.
Depends on the platform you are using and planning to learn on or will do future development.
On Windows you can use Visual Studio Express C++ which supports standard ANSI C usage. Option two is Cygwin which is a library and tool set that replicates much of what you would use on Linux or other Unix style OS's ( it uses GCC ).
On the Mac you would want XCode which is the standard development tools including C compiler ( based on GCC ).
On many Unix type systems it will be cc or gcc depending on the OS vendor.
If you have the money some of the paid compilers like the Intel one are exceptional but likely won't be much help in learning the programming craft at this point.
If you use LINUX operating system GCC is the best compiler. You can separate each compiler steps like preprocessing , assembler , linker separately in GCC compiler using some command line options. You can analyze step by step of compilation of your C source code easily. I suggest to go for "GNU C COMPILER(GCC)". You can use "CC" command, its nothing but a symbolic link to GCC.
I can recommend OpenWatcom which was once used to develop Netware. Only supports IA-32 but does it well. Contains a basic IDE and a basic but competent profiler. Something for the real programmer :)
Then there is Pelles C which supports x86-64. It has a basic VC-like IDE but few support programs.
I like these two because the compilers are competent and you get going quickly without having to pore over manuals and wondering what the options mean.
If you are on windows use MinGW or like most have suggested ggo with GCC on Linux
Though ofcourse since it's commandline so you might find Dev-C++ and/or Code::Blocks, Eclipse CDT etc which are IDEs useful for you to make your job simpler.
There is no standard and each compiler and it's libraries differ from one another.
gcc is best and free. GO FOR GNU!
I have C program which I wrote in Linux that runs very well. Now I want to run it on Windows.
How do I easily run it on Windows?
Elaborating a bit on the answers from caf and jartieda...
Cygwin is an attempt to emulate a (nearly) complete POSIX execution environment in a native Windows process. It is complete enough that a surprising amount of Unix application code simply compiles and runs using the familiar ./configure && make && make install idiom. This trick was done by supplying a DLL that emulates POSIX system calls using the Windows API. Based on that, you get a complete GCC toolchain, bash, and all the usual command line utilities you are used to. One downside is that the compiled program is dependent on the Cygwin DLL, which makes it tricky to deliver the result to a system that does not already have Cygwin installed and whose user doesn't want to use a Unix shell.
MinGW is a port of the GCC toolchain that generates native Windows applications that depend on the well known (and distributed with Windows itself) MSVCRT.DLL C runtime library. It makes no attempt to emulate a POSIX operating system, but applications that are mostly based on the standard C libraries, will often build essentially unchanged.
MSYS is a compile-time environment that provides enough Unix utilities (including bash) to often allow ./configure to run, and if the project supports the results, finish the build with MinGW's GCC. The result is a native Windows executable that does not depend on any DLLs you don't deliberately use aside from MSVCRT.DLL. Although the MSYS environment itself was a fork of an early version of the Cygwin project, it is primarily intended to be used to provide a unix-like place to compile native Windows applications: one would generally not build new applications based on its runtime environment.
Another approach to compiling for Windows is to use the MinGW cross compiler on linux. A number of MinGW's core developers work that way, testing they product either under Wine, or under Windows running in a VM or a separate PC.
If the program has a GUI component, then you may have additional difficulties. Some GUI frameworks are available for both Linux and Windows. Qt, wxWidgets, and IUP all leap to mind, but there are others out there.
Edit: I've improved the paragraph above about MSYS to emphasize that it is intended to be a compile-time environment for building programs that run as native Windows applications, and not a full POSIX environment like Cygwin.
Note, also, that there is always the option of porting the project to one of the more traditional compilers for Windows development. Open Watcom, the Borland compilers, and Microsoft all have free or inexpensive versions, although often enough not under licenses that make the opens source community entirely happy.
This approach probably requires more effort because the differences between a Linux environment and the Windows environment become more visible when you also switch from one toolchain to another. This is especially true of the Microsoft compilers which are historically not as fully standards compliant as GCC.
The easiest way is to install the Cygwin environment, and compile it under that.
best way recompile it all using mingw compiler.
easy way recompile it under cygwin environment.
The answers you got so far, focus on installing the GNU operating system on the Windows kernel; but you could also use freeware tools from Microsoft. This solution is probably most attractive if you want to continue to develop on Linux, and only do a little work for porting on Windows:
Microsoft offers a simplified version of their development environment as freeware: Visual Studio Express (download). If your program does only file IO it will probably compile unmodified, because Microsoft supplies the C standard library too.
For GUI I also wholeheartedly recommend the Qt framework. It is very well written and documented; it is now licensed under the LGPL, so you can link it to proprietary applications without any cost. However it is written in C++ so you would need to change the programing language. For integration of QT with Visual Studio Express: I believe it works, but you need to try it out. About five years ago I tested the integration of (proprietary) QT and (professional) Visual Studio for my employer, and it worked perfectly.
I would like to port a few applications that I use on Linux to Windows. In particular I have been working on wdiff. A program that compares the differences word by word of two files.
Currently I have been able to successfully compile the program on windows through Cygwin. However, I would like to run the program natively on Windows similar to the Project: UnixUtils.
How would I go about porting unix utilities on a windows environment?
My possible guess it to manually create the ./configure file so that I can create a proper makefile. Am I on the right track? Has anyone had experience porting GNU software to windows?
Update:
I've compiled it on Code::Blocks and I get two errors:
wdiff.c|226|error: `SIGPIPE'
undeclared (first use in this
function)
readpipe.c:71: undefined reference to `_pipe'
readpipe.c:74: undefined reference to `_fork
This is a linux signal that is not supported by windows... equvilancy?
wdiff.c|1198|error: `PRODUCT'
undeclared (first use in this
function)|
this is in the configure.in file... hardcode would probably be the fastest solution...
Outcome:
MSYS took care of the configure problems, however MinGW couldnt solve the posix issues. I attempt to utilize pthreads as recommended by mrjoltcola. However, after several hours I couldnt get it to compile nor link using the provided libraries. I think if this had worked it would have been the solution I was after.
Special mention to Michael Madsen for MSYS.
Yes. If you stick to the standard C library, and POSIX functions, most is available on Windows. You may just have to find the implementations. There are implementations of things that do not require Cywgin or MinGW (such as a pthreads package, etc.)
Also, there is a great book that is written in the style of W. Richard Steven's Advanced Proramming in the UNIX Environment, and the book is Windows System Programming, author Johnson Hart. He has a 4th edition. It focuses on System Programming, there is no GUI treatment whatsoever.
http://www.amazon.com/Windows-Programming-Addison-Wesley-Microsoft-Technology/dp/0321657748
It is the best book I know of for a UNIX programming moving to Windows.
You can have a look at MinGW (and MSYS), which are similar to cygwin, but gcc produce native Windows executables. However, since the Unix emulation is not as good as cygwin, you may have to adjust your code.
Always try to following standarts even when porting applications. POSIX compliant compilers exist on windows/Linux. You can try mingw. It has full toolchain required to build standart POSIX application (GNU Linux as well). Check out Dev-Cpp it eases the work.
MinGW is about the easiest way to get gcc and associated binary utilities (including gdb) on a Windows PC. It includes header files and import libraries so that you can call native Windows APIs. If you want more of an integrated IDE development environment you could download Microsoft's free Visual Studio Express C++.
Either way you'll likely have to convert some of the function calls to use Windows specific APIs (if you want a book I'd also recommend the Hart book mentioned in mrjoltcola's answer). For simple command line tools this conversion is usually not a huge deal, the big porting nightmares tend to involve tools with GUIs which have deep embedded dependencies on the GUI framework provided by the OS.