I've downloaded MinGW with mingw-get-inst, and now I've noticed that it cannot compile for x64.
So is there any 32-bit binary version of the MinGW compiler that can both compile for 32-bit Windows and also for 64-bit Windows?
I don't want a 64-bit version that can generate 32-bit code, since I want the compiler to also run on 32-bit Windows, and I'm only looking for precompiled binaries here, not source files, since I've spent countless hours compiling GCC and failing, and I've given up for a while. :(
AFAIK mingw targets either 32 bit windows or 64 bit windows, but not both, so you would need two installs. And the latter is still considered beta.
For you what you want is either mingw-w64-bin_i686-mingw or mingw-w64-bin_i686-cygwin if you want to compile for windows 64. For win32, just use what you get with mingw-get-inst.
See http://sourceforge.net/apps/trac/mingw-w64/wiki/download%20filename%20structure for an explanation of file names.
I realize this is an old question. However it's linked to the many times the question has been repeated.
I have found, after lots of research that, by now, years later, both compilers are commonly installed by default when installing mingw from your repository (i.e. synaptic).
You can check and verify by running Linux's locate command:
$ locate -r "mingw32.*[cg]++$"
On my Ubuntu (13.10) install I have by default the following compilers to choose from... found by issuing the locate command.
/usr/bin/amd64-mingw32msvc-c++
/usr/bin/amd64-mingw32msvc-g++
/usr/bin/i586-mingw32msvc-c++
/usr/bin/i586-mingw32msvc-g++
/usr/bin/i686-w64-mingw32-c++
/usr/bin/i686-w64-mingw32-g++
/usr/bin/x86_64-w64-mingw32-c++
/usr/bin/x86_64-w64-mingw32-g++
Finally, the least you'd have to do on many systems is run:
$ sudo apt-get install gcc-mingw32
I hope the many links to this page can spare a lot of programmers some search time.
for you situation, you can download multilib (include lib32 and lib64) version for Mingw64:
Multilib Toolchains(Targetting Win32 and Win64)
By default it is compiled for 64bit.You can add -m32 flag to compile for 32bit program.
But sadly,no gdb provided,you ought to add it manually.
Because according to mingw-64's todo list, gcc multilib version is done,but gdb
multilib version is still in progress,you could use it maybe in the future.
Support of multilib build in configure and in gcc. Parts are already present in gcc's 4.5 version by using target triplet -w64-mingw32.
gdb -- Native support is present, but some features like multi-arch support (debugging 32-bit and 64-bit by one gdb) are still missing features.
mingw-64-todo-list
Related
I'm looking for a cross compiler to compile for linux under the msys2 environment.
I'm looking for somethink like x86_64-w64-linux-gcc. But I can't find it.
Which package I have to install?
You'll need a VM or a Linux machine to test the resulting binaries, so I'd just compile on one in the first place.
But cross-compilation should be possible too:
Boot up your favorite Linux distribution in a VM.
Install the libraries you want to have. Install g++ to get libstdc++, and possibly other basic libraries.
Copy the root directory / from the VM to the Windows machine.
You only need headers and libraries, not everything. You'll have to experiment to know what directories can or can't be safely removed.
Install Clang on the Windows machine. Installing LLD is also a good idea (it's a separate package in MSYS2; or, if you're using the official Clang binaries, it's bundled with them).
We're using Clang, because it's inherently a cross-compiler, i.e. doesn't require separate binaries to target a different platform, unlike GCC.
Compile with Clang with --target=x86_64-pc-linux-gnu --sysroot=path/to/root/directory.
-fuse-ld=lld is probably a good idea as well.
The string x86_64-pc-linux-gnu was obtained by running clang++ --version on a Linux machine.
You might need a few more flags, but this should be a good starting point.
I have to install a package (spatial-correlation-sampler) which calls for gcc: >=5.3. On my system (Linux, remote server), gcc version is 4.8.5, and a Conda virtual environment uses the same version. Is it possible to use a different version within the virtual environment?
Is it possible to use a different gcc version inside a Conda environment?
Probably yes, except if you (or your Conda environment) needs or uses some GCC plugin. These plugins are specific to a particular version of GCC: a plugin coded for GCC 4.8 (such as my old GCC MELT) won't work with GCC 6. But see also this draft report on Bismon (which might become a successor to GCC MELT).
On Linux/x86-64, a C code compiled with GCC 4.8 would be compatible with the same code compiled with GCC 10, since both follow the same ABI and calling conventions.
For C++ code compiled with GCC, there could be subtle ABI or calling conventions incompatibilities (related to name mangling and exceptions).
Be also aware that Python 2 and Python 3 have different foreign function interfaces. Read chapters related to extending and embedding the Python interpreter.
See also the Program Library HowTo, Advanced Linux Programming and C++ dlopen mini-HowTo and Linux Assembly HowTo and of course Linux From Scratch.
On my system (Linux, remote server), gcc version is 4.8.5
GCC is Free Software.
You are allowed to compile and install a more recent GCC from its source code on your system. An installed GCC 4.8 can be use to build e.g. a GCC 8 from its source code (then installed into /usr/local/bin/gcc, then you just configure wisely your $PATH variable). You could even do that with the unsupported GCC 5.
On recent Debian or Ubuntu you would install dependencies with something like sudo aptitude build-dep g++ and you might also want to use Docker. You may need to download several gigabytes.
Some companies or freelancers are able (for a fee) to compile a GCC tailored for your system. I know AdaCore, but there are many others corporations or freelancers selling support on GCC. Contact me by email for more.
PS. On a powerful AMD Threadripper 2970WX desktop, I just built GCC 10.1 with make -j8 and g++ 9.3 on Debian/Sid in 10:21.38 elapsed time, requiring less than 7 Gbytes of disk space (for both GCC source code and object files). Of course, I disabled the compiler bootstrap. You could do the same thru ssh to your system (it could take an hour or two of elapsed time, because a Linux VPS has less cores so you might need to just make -j2).
My developing/producing environments are all CentOS-7.7.
In order to compile my program with gcc-8.3.0, I have installed "devtoolset-8" on my developing env, but it can not be used in the way same as gcc-4.8.5 that was shipped with CentOS7 oringinally.
Every time I need to compile a program, I must use "scl enable devtoolset-8 -- bash" to switch to gcc8 instead of gcc4.8.5.
When the program was deploying onto the producing-env, there is no gcc8, nor libstdc++.so.6.0.25, so it can not run.
I guess libstdc++.so.6.0.25 should be released with gcc8? I can neither install "devtoolset-8" on the producing-env, nor build gcc8 from source on the producing env.
The version of libstdc++ that can be installed from the official yum repo of CentOS, is libstdc++.so.6.0.19, hence my programs can not be loaded at the producing-env.
How to let such programs to run?
Thanks!
Pls forgive my Ugly English.
In order to not have to copy or ship a separate libstdc++.so but rather link statically (as suggested in a comment) against the C++ runtime, one can link C++ programs with -static-libstdc++ (also specifying -static-libgcc will also make sure that the program does not depend on a recent enough version of libgcc_s.so on the system - although that should rarely be a problem).
There can also be the issue of the target system having a version of glibc that is too old (relative to the build system). In that case, one could anyhow compile gcc of no matter how recent of a version on the older system, so that the resulting C++ executables as well as libstdc++ are linked against the older glibc. Linking C++ programs with -static-libstdc++ will again help to not depend on the program having to be able to find libstdc++.so at run-time.
Finally, the C++ program could also be linked with -static not depending on any dynamic libraries at all.
I'm trying to compile Pyaudio, (a Python module) from source, since I'm using Windows, and only 32-bit binaries are available - I need 64. Following these instructions I downloaded Cygwin, and installed every component, to be safe. Installing Portaudio, another module, is required first.
When I run CFLAGS="-mno-cygwin" LDFLAGS="-mno-cygwin" ./configure, I get the error configure: error: C compiler cannot create executables. See 'config.log' for more details. config.log has an additional line below that message: gcc: The -mno-cygwin flag has been removed; use a mingw-targeted cross-compiler.
This leads me to believe that perhaps Cygwin is using the wrong compiler; the instructions are for using MinGw with Cygwin, but I never specified minigw in the process. I also wonder if there's something in the PyAudio build files that needs to be changed for 64-bit. I know nothing about C, compiling, Cygwin or MinGW, and am new to programming in general. Any ideas? Any other information I can provide?
Current versions of Cygwin gcc do not support -mno-cygwin anymore because it never really worked correctly. Instead, you should use a proper cross-compiler, which is provided by the mingw64-i686-gcc packages, then run ./configure --host=i686-w64-mingw32.
In some cases it is an antivirus that is causing problems.
I had avast and had to disable it.
I am trying to make the ARM toolchain in ubuntu. The way it is specified in http://hri.sourceforge.net/tools/arm-elf-gcc.html
I am getting the following error:
Configuring for a x86_64-unknown-linux-gnu host.
Invalid configuration `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized
Invalid configuration `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized
Unrecognized host system name x86_64-unknown-linux-gnu.
does anybody have idea whats going wrong here.
A Google-search on the "machine `x86_64-unknown' not recognized" error message indicates that this can happen if the config.guess and config.sub files in the program you're building are too old to recognize the machine type for 64-bit linux. I expect that's your problem. You can fix that by replacing the ones in your GCC source tree with newer versions; your system should have some in the /usr/share/libtool directory that will work. Alternately, compile in a 32-bit Linux installation, or with "--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu" configure options.
There are also copies here:
http://cvs.savannah.gnu.org/viewvc/*checkout*/config/config/config.guess
http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.sub
The real question, though, is: Why you are trying to build a version of the ARM toolchain that's that old? The directions on the site you link to will lead you to download the sources for the 2.95.3 version of GCC -- which was released nearly a decade ago. In GCC terms, that's positively ancient; the latest version is 4.5. It's older than a lot of ARM instruction-set changes, too.
Thus, the right solution to your problem, unless you have some specific need for a 2.95 compiler, is to get a version of GCC that's much more recent.
Also, you'll probably save some pain by not compiling it yourself, unless you particularly want to. There are numerous sources of precompiled cross-compilers; since I work at CodeSourcery, I'll recommend ours (which you can download and use for free):
http://www.codesourcery.com/sgpp/lite/arm/portal/subscription?#template=lite. If you want something equivalent to the compiler on the page you linked to, you probably want the "uClinux" version.