I have installed mingW to use gcc, platform windows 7. I am trying to locate the standard C library libc.a in mingW folder. no luck.. is it stored in some other name?
MinGW does not build against glibc, it builds against msvcrt. As such, it uses libmsvcrtXX.a instead.
Related
I'm trying to build a C program with Windows gcc using Mingw-w64 installation (gcc.exe (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0).
I get undefined reference to `memmem' error. Isn't memmem() a standard glibc function that should be available in all gcc versions?
As this post explains
"MinGW does not build against glibc, it builds against msvcrt. As
such, it uses libmsvcrtXX.a instead." "gcc and glibc are two separate
products."
So, yep, no memmem on Windows and here's the implementation.
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.
I am using Eclipse CDT and MinGW to do C development on Windows 8.1.
I have unpacked company internal MinGW package and just copied it to c:\MinGW, so it was not installer. I also added c:\MinGW\bin to path.
When I run Eclipse CDT, it does detect MinGW toolchain. However, after I set up a C project and tell it to use MinGW toolchain, and build it, I see in the console output the C compiler used is gcc, and I would like to use mingw32-g++.exe.
How do I define this in Eclipse CDT?
I checked project Properties\C C++ Build\Tool Chain Editor\ and under used tools I see the following:
GCC Assembler
GCC Archiver
GCC C++ Compiler
GCC C Compiler
MinGW C Linker
MinGW C++ Linker
The compiler is defined under project properties \C C++ Build\Settings\Tool Settings. Here one should select GCC Compiler and specify mingw32-g++ or just g++, or whichever compiler is desired.
I am trying to compile native linux c files on windows using GNU GCC compilers. For the installation purpose, I have followed the steps mentioned by Faheem in the following link :
Using GCC(minGW) as Matlab's MEX compiler
the example given there compiled successfully. but when i am trying to compile a file using thread functions, the following error is being thrown:
fatal error: pthread.h: No such file or directory
#include
^
compilation terminated.
I have installed all the components from MinGW installer related to GNU C compiler bu still the error persists. Can any one suggest a way to solve this problem. Thanks in advance.
According to the TDM-GCC "Quircks" page, TDM-GCC includes a pthreads emulation layer for Microsoft Windows systems, called "winpthreads", and a recent toolchain you should have x86_64-w64-mingw32\include\pthread.h in the TDM install path. So, I don't know what is wrong with Faheem's instructions, but you should have no trouble including pthread.h if MATLAB is configured correctly.
What is not stated on the TDM Quircks page is that TDM uses Winpthreads from the MinGW-w64 project. From the current README installed with TDM:
"Winpthreads" is one of the libraries distributed by the MinGW-w64 project, and
it allows GCC to be compiled with full pthreads compatibility, which is
necessary to enable std::thread and other threading related functions in the
C++ runtime.
As it states, Pthreads is part of the MinGW-w64 project and you can also get it with MinGW-w64 if you pick a pthreads enabled toolchain. For MinGW-w64, I do the following to set it up (see here for more details):
Grab the latest revision for w64 from Sourceforge (or use the installer to choose the toolchain you want, picking a pthread version).
Extract it so that you have a path to the compiler like C:\mingw-w64\x86_64-4.9.2-release-posix-seh-rt_v3-rev1\bin\x86_64-w64-mingw32-g++.exe. There is no need for MSYS, cygwin, or any other environment if you plan on compiling in MATLAB with mex.
Set it up with a custom mexopts.bat or using the new xml configuration system. On my GitHub repo, I have C++ configurations for MinGW-w64 in both file types: mingw_mexopts.bat and mex_C++_mingw-w64.xml. For example, using the xml file to set up C++ MEX file compilation:
mex -setup:C:\Users\Jon\Documents\MATLAB\mex_C++_mingw-w64.xml C++
If needed, set up the C compiler in a similar manner by modifying the config files.
I posted a more detailed version of the above instructions in my answer to the canonical question on the MinGW-with-MATLAB topic.
I want to be able to develop in C using the Netbeans IDE in my Windows environment, but can't figure out how to install the standard library headers for C on a Windows machine.
Google searches offered no success.
Tips?
Thanks.
If you want POSIX support and are used to programming in a Linux environment, take a look at Cygwin, which uses the newlib C library. Otherwise you're probably looking for MinGW, which compiles against the Microsoft C run-time library.
Both Cygwin and MinGW provide their own set of headers for the standard C library.
Developing with Cygwin will require its libraries to be installed on client machines. However, you can build with the mno-cygwin compiler flag to instead use the MinGW-32 headers and runtime libraries.
MinGW binaries should run on Windows clients without installing any extra libraries.