So I've been reading online but I'm still very confused. I understand that there are different tools in the Linux-on-Windows world: Msys, Msys2, Cygwin, Mingw and Mingw-64.
Here is what I think I know, and please correct me if I'm wrong:
Mingw aims to simply be a port of the GCC programs to Windows. It creates native Windows binaries and that's it.
Mingw-64 is just a more recent and better supported version of Mingw that also supports Windows 64 bit.
Cygwin, while also including Mingw (?) to support GCC on Windows, provides a POSIX compatibility layer through a DLL that all programs are linked to by default.
MSYS is a fork of Cygwin, but it drops some of the POSIX compatibility efforts. Instead it mostly aims to allow creating native Windows program. But - they will still be dependent on a MSYS DLL being present.
MSYS2 is just a more recent and active version of the less active MSYS.
Is this all true? If it is, here is what I want to validate:
Essentially, I think all I should need for my development is Mingw in order to use GCC to build native Windows applications. I don't need a POSIX layer, and I don't want my program to depend on any DLL apart from the ones that are present on Windows systems anyway. As far as I understand, this is what Mingw offers.
However, somehow I managed to install MSYS (or MSYS2? I'm not sure anymore) on my system. The tutorial I was following early on suggested doing so.
Since it seems MSYS(2) includes Mingw under C:\msys64\mingw64, I just use the Mingw binaries directly from the Windows CMD without going through the MSYS(2) shell program. For example, I just added C:\msys64\mingw64\bin to the PATH and I run gcc from the Windows CMD directly to compile my project.
Is this a valid way to use Mingw? Or am I expected to run into problems?
Does this approach create pure Windows native binaries which should never depend on any MSYS(2)-related DLL?
Is it true that the MSYS(2)-related functionality and dependencies only come into play if I launch the Mingw programs (such as GCC) through the msys2.exe shell program? And so if I want to avoid any MSYS(2) or Cygwin related stuff, and simply use pure Mingw GCC, is it an okay approach to just launch GCC directly under the Mingw directory as described earlier?
Update: I have now checked using Dependency Walker, and running C:\msys64\mingw64\bin\gcc from the MSYS2 shell still creates an .exe with no special dependencies (which is good). So what is this msys-2.0.dll that the MSYS2 docs speak of? And how is using MSYS2 to compile C different than just using Mingw?
You're mostly right about what these projects are. MSYS2 does provide an evironment for POSIX programs like Bash, GNU Make, and other utilities, but it also provides a package manager named pacman that you can use to install lots of other things. In fact, you can use pacman to install a mingw-w64 toolchain.
MSYS2 provides two mingw-w64 toolchains actually: you get a choice of an i686 (32-bit) toolchain which makes native Windows binaries that can run on any Windows computer, or an x86_64 (64-bit) toolchain that makes native Windows binaries that only work on 64-bit Windows. You can install both of these at the same time.
You say "I don't need a POSIX layer", but you might find it useful to be able to write Bash scripts or use POSIX programs provided by MSYS2 like GNU Make when building your native Windows software. This is especially useful if you want to someday build your software on Linux or macOS: it's possible to write a simple Makefile or shell script that works on those platforms and also MSYS2.
Yes, it's valid to use the binaries from C:\msys64\mingw64\bin directly if you want to.
Yes, the mingw-w64 toolchain creates native Windows binaries regardless of which shell you happen to run it from.
No. Whether you start MSYS2 via msys2.exe, mingw32.exe, or mingw64.exe, you get a Bash shell with various Linux utilities available like ls, grep, make, and tar. The shell and those utilities use the POSIX emulation provided by msys-2.0.dll. The main difference between those MSYS2 launchers is what gets added to your PATH, so you might want to run echo $PATH and env in each of those environments and compare the results.
I'd strongly recommend using MSYS2 instead of MSYS and mingw.org . Pretend those latter two don't even exist. Being under active development the newer projects are better in every way.
MSYS2's package manager can deliver toolchains for the following target systems:
Standalone Win32 (i686)
Standalone Win64 (x86_64)
MSYS2 i686
MSYS2 x86_64
The former two cases can be invoked from any shell you like. You may need to set up paths if not using the launch script provided by MSYS2. They produce native Windows executables. Using the default switches to GCC there will be some dependencies, such as libgcc_s*.dll . Doing a static build with -static will produce an executable with no dependencies other than Windows DLLs.
In the latter two cases, the binary will depend on the MSYS2 DLL, and other things, but this provides support for a range of POSIX functionality.
[~ MSYS]$ ls /usr/include
_ansi.h cursesp.h glob.h net strings.h
_newlib_version.h cursesw.h gnumake.h netdb.h symcat.h
_syslist.h cursslk.h grp.h netinet sys
a.out.h cygwin icmp.h newlib.h sysexits.h
acl devctl.h ieeefp.h nl_types.h syslog.h
aio.h diagnostics.h ifaddrs.h panel.h tar.h
alloca.h dirent.h inttypes.h paths.h term.h
alpm.h dis-asm.h io.h plugin-api.h term_entry.h
alpm_list.h dlfcn.h langinfo.h poll.h termcap.h
ansidecl.h elf.h lastlog.h process.h termio.h
ar.h endian.h libfdt.h pthread.h termios.h
argz.h envlock.h libfdt_env.h pty.h tgmath.h
arpa envz.h libgen.h pwd.h threads.h
asm err.h limits.h reent.h tic.h
assert.h errno.h locale.h regdef.h time.h
attr error.h machine regex.h tzfile.h
bfd.h eti.h magic.h resolv.h ucontext.h
bfd_stdint.h etip.h malloc.h sched.h unctrl.h
bfdlink.h fastmath.h mapi.h search.h unistd.h
bits fcntl.h math.h semaphore.h utime.h
byteswap.h fdt.h memory.h setjmp.h utmp.h
complex.h features.h menu.h signal.h utmpx.h
cpio.h fenv.h mntent.h spawn.h w32api
ctf.h FlexLexer.h monetary.h ssp wait.h
ctf-api.h fnmatch.h mqueue.h stdatomic.h wchar.h
ctype.h form.h nc_tparm.h stdint.h wctype.h
curses.h fts.h ncurses stdio.h winpty
cursesapp.h ftw.h ncurses.h stdio_ext.h wordexp.h
cursesf.h gawkapi.h ncurses_dll.h stdlib.h xlocale.h
cursesm.h getopt.h ncursesw string.h
[~ MSYS]$
[~ MSYS]$
[~ MSYS]$ ls /usr/include/sys
_default_fcntl.h acl.h fcntl.h mman.h quota.h signal.h stdio.h termio.h ttychars.h utsname.h
_intsup.h cdefs.h features.h mount.h random.h signalfd.h strace.h termios.h types.h vfs.h
_pthreadtypes.h config.h file.h msg.h reent.h smallprint.h string.h time.h ucontext.h wait.h
_sigset.h custom_file.h iconvnls.h mtio.h resource.h socket.h sysinfo.h timeb.h uio.h xattr.h
_stdint.h cygwin.h ioctl.h param.h sched.h soundcard.h syslimits.h timerfd.h un.h
_timespec.h dir.h ipc.h poll.h select.h stat.h syslog.h times.h unistd.h
_timeval.h dirent.h kd.h procfs.h sem.h statfs.h sysmacros.h timespec.h utime.h
_types.h errno.h lock.h queue.h shm.h statvfs.h sysproto.h tree.h utmp.h
Cygwin is a competing product also providing POSIX functions and depending on a Cygwin DLL. The MSYS2 target is a fork of Cygwin.
Related
I want to install MinGW-W64 for Windows 10 64 Bit (must run on Version 1607!). First problem is which MinGW should I download, there are 3 versions on download page: 1) "MingW-W64-builds", 2) "Msys2", 3) "Win-Builds". I have choosen 1). If this was wrong for my purpose (see below) please tell me.
When I start the installer I have to choose the following options, which I'm not clear what to choose:
Architetcture: i686 or x86_64
Threads: posix or win32
Exception: dwarf or sjlj
Purpose (What I want to do)
I want (later) to install the CLang C++ 64 bit Compiler, which AFAIK requires the libraries from MinGW-64.
I want to write native Windows 64 bit C++ (at least C++ 14) and C applications (compiled with either GCC or CLang). I don't need a bash (or someone tells me a good reason why I should use it instead of the excellent Windows Powershell).
At a later time I want to be able to install an IDE (like Eclipse) which especially integrates the debugger (the one for GCC and if it is a different one for CLang that for CLang).
The sources should be as compatible as possible to sources which can be compiled with Visual Studio and the produced binaries should also be as compatible as possible with code produced with Visual Studio (unfortunately I cannot use VS Community version because of license reasons).
(Maybe this is usefull for answering: Python 2.7.11 and Python 3.7 are installed on my machine)
MSYS2 is an environment that gives you a UNIX-like shell.
You can use this if you need to use UNIX-like build tools (like autoconf).
If that's not what you need, don't install it.
Certainly don't build for MSYS as it's closer to Cygwin POSIX emulation than native Windows.
You will need a GCC compiler build against MinGW-w64.
For example one of the MinGW-w64-builds from: https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/
However, there don't seem to be any recent builds posted there, while there were newer releases of both GCC and the MinGW-w64 libraries. So I have built more recent versions and published them at: http://winlibs.com/
On http://winlibs.com/ there are also some instructions on how to compile from the command line and how to set up the compiler in the Code::Blocks IDE.
If you need Clang instead of GCC there are Windows binaries available at: http://releases.llvm.org/
However, you will still need the MinGW-w64 libraries to build for Windows using CLang. So if you're new to this, maybe you should just start with GCC before moving on to CLang.
Keeping your code compatible between compilers or even operating systems is up to the programmer.
The key rule there is to avoid anything compiler or operating specific, and if you really must then enclose them in conditional defined (e.g. put the specific code between #ifdef __MINGW32__ or #ifdef _WIN32 and #endif).
I'm writing an application that uses ncurses.
In Debian and Ubuntu, I have the choice between these packages:
libncurses5-dev
libncursesw5-dev
The w version includes wide-char support, which is what I want.
However, if I only install libndursesw5-dev, I get an error message when I compile with -lncurses or -lncursesw where it tells me it can't find curses.h or ncurses.h.
Installing both libncurses5-dev and libncursesw5-dev and using -lncursesw works, but I'm not sure if that is the proper way or just coincidentially seems to work. Using -lncurses will bring in a non-wide-char library.
For reference, on Mac OS X 10.11, -lncurses works (with wide-char support) and -lncursesw doesn't work at all.
Debian installs the two headers
/usr/include/curses.h
/usr/include/ncursesw/curses.h
as a workaround for compatibility. The latter is "mostly" compatible, but only at compile-time. For instance the WINDOW structure is larger in the latter. The first (/usr/include/curses.h) is "standard", but preceded the ncursesw library by several years. Because some of the platforms to which ncurses was ported do not use ncurses as the system curses library (e.g., Solaris), provision was made for putting ncurses' header in a subdirectory to avoid overwriting (or conflicting with) the system's standard curses.h (see the ncurses FAQ Is the ncurses library compatible with my system?).
Since Debian started with ncurses as the system curses library, its packagers chose to use the same workaround to avoid conflict between ncurses and ncursesw. Packagers on some other systems could choose to put both in subdirectories and make a link in their packaging scripts like
/usr/include/curses -> /usr/include/curses/ncurses.h
I recall that Cygwin did something like that, and omitted the link for unctrl.h (a bug, because it too is a standard header).
For OSX, the system provides only ncurses (not ncursesw), and most people using ncursesw do this via something like MacPorts, which installs the ncursesw header (which works well enough if the application defines _XOPEN_SOURCE_EXTENDED when compiling for ncursesw,
since the declaration of WINDOW is ifdef'd to allow either library to be supported). The Debian packagers were more cautious and chose to keep the headers separate.
I created a software that has native components and therefore requires the creation of operating system specific shared libraries (.dylib , .dll and .so ). I have a Mac OSX and I have already created a version of the software that is compatible with Mac OSX machines. I need to release versions that are compatible with other operating systems. Can I simply go on my mac terminal and write:
gcc -o c_prog.dll -shared c_prog.c
and
gcc -o libc_prog.so -shared c_prog.c
Or do I have to create the .so and .dll files on their respective operating systems?
What you suggest is NOT possible. Your compiler can create code for ONE specific target platform, specified by the "host triplet", for example on my linux machine:
> gcc -dumpmachine
x86_64-linux-gnu
Meaning of the host triplet ist $(machine)-$(vendor)-$(operatingsystem).
GCC (and probably some other compilers) can be built as a cross compiler. This is a compiler with a different target host-triplet from the machine it is running on. For my system (Debian Linux), there is a ready made package of GCC for compiling windows 64bit binaries: gcc-mingw-w64-x86-64. So in theory, you can build everything on your system. But don't forget you need the target platform's header files, the matching binutils (for things like packaging a shared library) and a linker and standard C library for the target platform. All together is called a cross toolchain.
Now you could look around for a cross toolchain to target Linux and Windows on your Mac. Maybe you will find something working. Or you could take the though path and try to compile your cross tools yourself from gcc, glibc and binutils sources.
In the end, I resorted to using a real Windows virtual machine for building my software, that I developed on Linux, for Windows. This was a lot easier :)
I can currently compile C programs with stdio.h and such like for Windows with the command i586-mingw32msvc-gcc, however I cannot do this for a GLUT program. When compiling it for Linux I use:
gcc main.c -lglut -lGLU
(I know, bad practice as it comes out with a.out)
Yet I am unsure of how I could do it for Windows using mingw32. When I run
i586-mingw32msvc -lglut -lGLU
it returns:
test.c:3:21: error: GL/glut.h: No such file or directory
The included header files are:
#include <GL/gl.h>
#include <GL/glu.h>
#include <GL/glut.h>
And I am unsure of how to make it able to compile. Any ideas?
Essentially that error tells you, that your MinGW GCC does not find the required headers. That is, because you're cross-compiling to another OS, and header files may contain OS specific things. Unfortunately OpenGL is one of those. So you have to install the required libraries in a Windows version as well.
However you should not just download some precompiled binaries from the web; you need libraries matching MinGW. You can of course install MinGW built libraries, that will work. However I suggest something different: Crosscompile and locally install all the libraries you require in your MinGW environment yourself. You do this, by passing the right compiler, linker and prefixes into the build configuration of each library. For example for autoconf based configure (on my system)
CC=i686-mingw32-gcc CXX=i686-mingw32-g++ ./configure --prefix=/usr/i686-mingw
make ; make install will then build and install the libraries and their headers in the MinGW environment, where you can use them as any other regular installed library.
In the gcc manual it is given that "The C standard library itself
is stored in ‘/usr/lib/libc.a’". I have gcc installed, but could not find libc.a at the said location. Curious to know where is it located.
I find many .so files in /usr/lib location. What are those?
If you are looking for libc.a:
$ gcc --print-file-name=libc.a
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libc.a
A few things:
gcc and glibc are two different things. gcc is the compiler, glibc are the runtime libraries. Pretty much everything needs glibc to run.
.a files are static libraries, .so means shared object and is the Linux equivalent of a DLL
Most things DON'T link against libc.a, they link against libc.so
Hope that clears it up for you. As for the location, it's almost certainly going to be in /usr/lib/libc.a and / or /usr/lib/libc.so. Like I said, the .so one is the more common.
If you are on RPM based Linux (Red Hat/CentOS/Fedora/SUSE) then you would get the location of the installed glibc with
rpm -ql glibc and rpm -ql glibc-devel .
locate libc.a would get you the location. And to see from where it comes do:
rpm -qf /usr/lib/libc.a
Here is what rpm -qi has to tell about these packages
glibc-devel:
The glibc-devel package contains the object files necessary
for developing programs which use the standard C libraries (which are
used by nearly all programs). If you are developing programs which
will use the standard C libraries, your system needs to have these
standard object files available in order to create the
executables.
Install glibc-devel if you are going to develop programs which will
use the standard C libraries
glibc:
The glibc package contains standard libraries which are used by
multiple programs on the system. In order to save disk space and
memory, as well as to make upgrading easier, common system code is
kept in one place and shared between programs. This particular package
contains the most important sets of shared libraries: the standard C
library and the standard math library. Without these two libraries, a
Linux system will not function.
You need to install package for static libraries separately:
glibc-static.i686
On centos 5.8
$ ls -l /usr/lib/libc.a
-rw-r--r-- 1 root root 2442786 Apr 8 2010 /usr/lib/libc.a
$ rpm -qf /usr/lib/libc.a
glibc-devel-2.3.4-2.43.el4_8.3
You also have to have the glibc-devel package install under RedHat distributions.