Question
As I understand from boost.org, MinGW in not supported, that is, if Boost library (or program using Boost) is compiled with MinGW, then it is unstable.
Is it correct?
If it is, then what is going on with bitcoin (it is compiled on Windows with MinGW)?
Link
http://www.boost.org/doc/libs/1_55_0/more/getting_started/windows.html#pch
Excerpt from the link
"A note to Cygwin and MinGW users
If you plan to use your tools from the Windows command prompt, you're in the right place. If you plan to build from the Cygwin bash shell, you're actually running on a POSIX platform and should follow the instructions for getting started on Unix variants. Other command shells, such as MinGW's MSYS, are not supported—they may or may not work."
Thanks in advance,
--- Kosta
Only MinGW's MSYS command shell is not supported.
MSYS is a collection of GNU utilities such as bash, make, gawk and grep to allow building of applications and programs which depend on traditionally UNIX tools to be present. It is intended to supplement MinGW and the "deficiencies" of the cmd shell.
BUT you can build Boost library with MinGW and b2 under the standard Windows cmd.exe command prompt.
With MinGW installed and paths correctly set, usually these two commands are enough:
bootstrap.bat mingw
b2 threading=multi toolset=gcc
Once you have the libraries you can use them under the MSYS environment.
Related
I built neovim with MSYS2 MINGW64 compiler. It built great. But the build script forces me to build it from a normal shell (cmd/pwsh).
# These are native MinGW builds, but they use the toolchain inside
# MSYS2, this allows using all the dependencies and tools available
# in MSYS2, but we cannot build inside the MSYS2 shell.
And since it was built from outside the MSYS2 shell, the debug info in the executable is set to native Windows filesystem, e.g. F:\projects\neovim\. So, now when I invoke gdb from inside MSYS2 shell, most things work perfectly, except the source-code listing. The list command tells me the filename and linenumber but not the actual code.
I ran gdb from a native shell (pwsh), from the MSYS2/MINGW64 bin directory, and from there I can see the source-code listing. So I'm almost certain the problem is MSYS2 using unix filesytem, e.g. /f/projects/neovim.
For some personal reasons, I have to use the gdb from MSYS2 shell. I cannot use the gdb from the native Windows shell. Native shell doesn't work well with my gdb config, which was built for my Linux environment and uses gef.
So, is there a way I can set the source-code directory to Windows-style in MSYS2 for a session? Or maybe I can set the source-code directory to MSYS2-style when building the project?
GNU has cross-platform toolchains. You can use those to (kind of) build and debug programs for other platforms. For simplicity, we'll concern ourselves only with gcc and gdb.
Both gcc and gdb has cross platform versions, so you can be on Linux/Windows and compile C programs for Windows/Linux. These GNU tools have compilation arguments called host and target. So you can compile gcc/gdb to run on Windows system and compile/debug programs for Linux system.
The mingw64 gdb has both target and host set up to be x86_64-w64-mingw32. So it runs on Windows system and debugs programs compiled by Mingw-w64 toolchain.
The Msys2 gdb, on the other hand, has target and host set up to be x86_64-pc-msys. So it'll only run on msys systems, which means you'll have to invoke it from inside the Msys2 shell (Otherwise it won't find the cygwin.dll and won't perform properly, if it does at all). Moreover, it can only debug programs compiled for msys systems.
Â
In short, to debug programs compiled by Mingw-w64 toolchain, use the mingw64 gdb.
If I have installed MinGW and Cygwin (on Windows 7), which one will be used when the gcc compiler is invoked on the Windows MS-DOS shell command line?
If it is ambiguous, how can I figure out which one of the two packages' GCC is used?
If memory serves neither one modifies your system PATH. So if you just open cmd.exe you are probably going to get a
gcc not found
If you want to use GCC you will need to open the Bash prompt for Cygwin or MinGW.
I am using Cygwin and have GCC (version 4.3.4 20090804 (release) 1 ) installed as Cygwin package.
When I built C code using GCC under Cygwin shell, the generated executable output file is a executable of type (PE32 executable for MS Windows (console) Intel 80386 32-bit) and it can only be executed/run under Cygwin shell, not as standalone .exe on Windows shell/command prompt. If I try to run it standalone on Windows command prompt it gives an error window saying "The program can't run because cygwin.dll is missing from your computer".
How can one make this .exe standalone, which can be executed on a command prompt of any other system or even in my own system?
I thought GCC under Cygwin would build a Linux executable (ELF 32-bit LSB executable), but it's not so. How can I use the gcc-cygwin combination to generate a *.out kind of Linux executable file?
Also, I cannot run a Linux executable generated on a Linux-gcc combination to execute under Cygwin.
Any pointers would be helpful.
Despite widespread rumours, Cygwin is not a Linux emulator, i.e. it doesn't produce or run Linux executables. For that you'll need a virtual machine or coLinux.
Instead, Cygwin is a compatibility layer, which aims to implement as much as possible of the POSIX and Linux APIs within Windows. This means that programs have to be compiled specifically for Cygwin, but it also means that it's better integrated with Windows, e.g. it lets you mix POSIX and Windows APIs in the same program.
It's the cygwin1.dll that provides that compatibility layer. If you build non-Cygwin executables using gcc-3's -mno-cygwin switch or one of the MinGW compilers, then of course you can't use any POSIX/Linux-specific APIs, and any such calls will need to be replaced with Windows equivalents.
Cygwin is an emulation layer. It allows UNIX code to run on Windows, if you compile it to use the emulation layer. To Windows it looks like any normal DLL and makes OS calls as normal. But when you compile against it, it shows the same functions as UNIX (well, POSIX technically, but UNIX it is)
1) When you build with cygwin, it automatically brings in this cygwin1.dll. This is the code that you need to make it look like UNIX. There are flags to make it not use this cygwin dll, meaning ignore the UNIX stuff and use native Windows calls. the -mno-cygwin flag will make the binary a native Windows binary, not using cygwin emulation. As others have said, you also need the -mwindows to make actual GUI apps using cygwin gcc.
2) To compile on one platform to run on another platform, you need what's called a cross compiler. You also need the libraries and headers for the other system. For what you want you'd need a cygwin-Linux cross compiler, Linux headers and libraries. It would probably be much easier to run Linux in a virtual machine than to set this up.
3) Remember that Cygwin just looks like UNIX to UNIX source code, not to Linux binaries. Once you compile things, the function calls are windows DLL calls. A cygwin program is still a Windows program (which is why you need a Windows style DLL to run it). Cygwin provides code for UNIX functions/system calls such as fork(), but even the method of calling them is now different. fork() now calls into a Windows DLL, not into a Linux kernel. It's still a very different system.
Not a complete answer, but I think I am able to give some pointers.
1) http://www.cygwin.com/cygwin-ug-net/programming.html says you should use -mswindows parameter. Take a look of MinGW.
2) You need a cross gcc to do this. By default cygwin gcc produces binaries linked against cygwin.dll.
3) That it because it is a linux binary. Easiest way is to recompile software in cygwin.
ad 1) There are currently three different mingw cross-compilers available for cygwin:
The old gcc3 -mno-cygwin is deprecated.
There are new mingw64 cross-compilers for 32 bit (mingw64-i686-gcc) and 64 bit windows targets (mingw64-x86_64-gcc).
There's no mingw-i686-gcc matching the official cygwin gcc4 compiler yet.
ad 2) There's no linux cross-compiler as cygwin package yet available. But people report success building such a cross-compiler by themselves.
ad 3) There's no cygwin cross-compiler as linux package available, but many mingw cross-compilers. Those mingw executables can also be executed under cygwin, though they cannot use cygwin features, just the simple windows runtime.
Correcting errors in others people posts:
-mswindows is not valid, -mwindows tells the linker to generate a GUI app without console.
-mno-cygwin is only valid for the old deprecated gcc3 compiler and is not supported anymore. Don't use it. With cygwin you should use ordinary host and target triples as with every other cross-compiler.
You need to have cygwin.dll in your path.
Or just use MinGW to compile native windows code without dependencies.
I have cygwin on windows through which I run gcc. But after creating .exe files, if I run them on other computers which dont have cygwin, it says cygwin1.dll not found. Is there a way to compile them so that they run on any system?
You need to compile for MinGW (Minimal GNU Win32) mode. You do that by either installing mingw instead of (or in addition to) cygwin, or by passing the --mno-cygwin compiler option to the cygwin gcc.
In your case, try to copy cygwin1.dll as well (but it could depend on other DLLs as well) (of course you must comply with Cygwin's license with regards to distributing cygwin1.dll)
In cygwin, you can always check the needed modules using:
objdump -p a.exe | grep 'DLL Name'
OR
cygcheck ./a.exe
or for windows in general, use something like this tool: Dependency Walker
You can try compiling with the command line option -mno-cygwin.
See the Cygwin FAQ.
From http://cygwin.com/faq/faq.html#faq.programming.win32-no-cygwin
How do I compile a Win32 executable that doesn't use Cygwin?
The compilers provided by the mingw-gcc, mingw64-i686-gcc, and mingw64-x86_64-gcc packages link against standard Microsoft DLLs instead of Cygwin. This is desirable for native Windows programs that don't need a UNIX emulation layer.
This is not to be confused with 'MinGW' (Minimalist GNU for Windows), which is a completely separate effort.
I've installed cygwin environment on Windows.
There is gcc 4.3. How to install gcc 4.4 in this environment?
The alternative is to build one yourself, but it will be extremely slow on cygwin. If you are a Linux user, you can build a native compiler (which runs in cmd.exe on windows, and produces native win32 binaries) on Linux. It is much faster (order of magnitude faster in my experience).
Otherwise, mingw is a good solution, although in my experience, the binary from equation.com work better for gcc 4.4 (there is no official gcc 4.4 from MinGW yet)
If you don't need the cygwin environment for special reasons, I'd go for Mingw with the gcc 4.4. You can find builds on: http://www.tdragon.net/recentgcc/.
Reading the MinGW FAQ, reveals that its possible to pass requests to use the MinGW binaries instead of the ones shipped with Cygwin.
For those who would like to use the Cygwin environment for development, yet generate non-Cygwin-dependant executables, a much easier option to "-mno-cygwin" does exist. Simply install Cygwin and the MinGW distribution in separate directories (i.e. "C:\CYGWIN" and "C:\MINGW"), and make sure that the "/bin" subdirectory beneath your MinGW installation comes before Cygwin's "/bin" subdirectory in your PATH environment variable (i.e. "PATH=%PATH%;C:\MINGW\BIN;C:\CYGWIN\BIN"). This will allow you access to all the UNIX tools you want, while ensuring that the instance of GCC used is the MinGW version. %%%
Bear in mind that within the "/etc/profile" file, Cygwin by default places "/usr/local/bin", "/usr/bin", and "/bin" ahead of your system-level PATH. Therefore, it is not enough to have the MinGW's "/bin" ahead of Cygwin in your Windows path... it must also be set to come first within the Cygwin environment (either by modifying "/etc/profile" or setting it manually).