On the SourceForge page for MinGW, you can download the GCC 4.5.2 and that's the latest version. On the GNU mirrors, you can download the GCC 4.6 source and compile it with one of the possible windows targets:
i[3456789]86-w64-mingw*
i[3456789]86-*-mingw*
x86_64-*-mingw*
Is there a difference between using one of these targets and the traditional GCC for MinGW? Would it make sense to use the regular GCC because it has more up-to-date versions or would it make more sense to wait until an up-to-date GCC for MinGW is released?
As you can see in the README file accompanying the MinGW release of GCC on SourceForge, no local patches were used, and I think this has been the case for quite a while now, so assuming there were no changes in the GCC codebase that require new local patches, you can very well download the GCC sources from one of the mirrors and build them yourself.
I have done so myself in the past, especially because I use gfortran, which is under quite heavy development, so from time to time I take the most recent snapshot and build that myself, so I can use certain new features that were only recently introduced.
(I have to admit that it took some trying to get the build to run without errors, and after a period without problems, I recently ran into some new ones that I couldn't completely smooth out. I will have to try again soon.)
Related
I have to compile 3 versions of gcc, say 9, 10 and 11.
My system gcc is version 8 (let's say).
Question : do I have any advantage on compiling gcc-v9 with gcc-v8, gcc-10 with gcc-v9 and gcc-v11 with gcc-v10 ?
Or I don't have any advantage and I can compile them all the gcc-v8 ?
Thank you for pointing out some directions for further research.
GCC has a "bootstrap" build process. So when you try to build gcc-11 with only gcc-8 installed, it will build a temporary "stage 1" version of gcc-11 using gcc-8, then compile gcc-11 again using gcc-11-stage1. Thus no matter what you start with, the version of gcc-11 that comes out of the build process was effectively compiled with itself.
So all that matters is that gcc-8, or whatever "system compiler" was previously installed, is able to build a stage1 version of gcc-11 that runs well enough to compile the stage 2 version. It doesn't matter whether your system compiler is good at optimizing, and gcc's source code is deliberately written to use a fairly minimal set of language feature (at least for stage 1), so you are not likely to run into trouble with your system compiler having missing or buggy support for obscure corners of the language. Historically, the "system compiler" was often not gcc at all, but some compiler provided by the computer vendor or an unrelated third party, and so one couldn't rely much on its quality; gcc was designed with that in mind.
Theoretically your system compiler could have a bug which miscompiles gcc-11-stage1 in such a way that it appears to work, but itself miscompiles stage2. This is unlikely, and it's even less likely that it would happen in a way that wasn't obvious (e.g. the stage2 compiler simply segfaulting). If worried, there's an option to have stage2 build a stage3 compiler, and then check that both versions are identical. So as long as the build completes, you can be pretty confident that the final installed compiler is fine and unaffected by bugs in the original system compiler. (All that said, a reference to Ken Thompson's "Reflections on Trusting Trust" is obligatory here.)
So in practice, you don't need to worry about the version of gcc used to build a new version. Whatever you happen to have installed already, within reason, will be fine.
I downloaded the latest source code of Opensplice DDS from https://github.com/ADLINK-IST/opensplice and tried to build it by following its instructions (source setenv, source ./configure, then make ..) in my Cygwin 64 bit.
The build (make command) appeared to be completed, but a number of modules such as dcpsisocpp2, durability, spliced didn't get built (I can't find dcpsisocpp2.dll, etc).
I wonder if anyone who is familar with Opensplice's makefile system can direct me to solve the problem.
You should identify you are going to use community or enterprise version.
It seems the community version doesn't have spliced and durability services. Also, dcpsisocpp2 use C++03 which is a very old C++ standard, that when you use C++11 or C++14 writing your application, you might get some warning or error and spend lots of time fixing compile problems.
Try to use dcpssacpp which follows the C++11 standard.
Of course we all know building GCC version >= 4.1.x requires the supplementary packages MPFR, GMP and MPC to be present.
There's a few ways to handle these GCC dependencies:
1) Download and build each supporting package separately and then tell make where the binaries are located during GCC build time.
2) Download each supporting package, untar and move the source into your GCC build directory and make will automatically build each of the packages when needed.
(Executing the gcc-src/contrib/download_prerequisites script does the same as option 2)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Is there an advantage to either method? Does pre-compiling the binaries provide something I'm missing by taking the "easy route" and just dumping the package's source into my GCC build directory and letting make figure it out?
I've seen it done more frequently in various build scripts by pre-compiling each package to a binary, and then telling make where they are located during gcc compilation. Is this the "preferred" way to do it? Why?
To add context, I'm mainly building cross-compilers targeting various ARM platforms.
For most use cases I believe that option 2 is just as good as option 1. However, I can see a few situations in which one would want to do it manually.
A package maintainer wants to build separately as they want separate packages for mpfr et al.
Someone who wants to pass different configure arguments/CFLAGS to each of the packages.
A GCC developer who wants to keep their source and build trees small as they don't make any changes to MPFR/GMP/etc.
I haven't done too much work with the (rather ugly) GCC build system, but I haven't seen any obvious differences in how the binaries are built.
I'm not the biggest authority on this though, so YMMV; I may be wrong.
I am working on CentOS 6 machines, which has very old GCC/GlibC version. I want to build the whole glibc, binutils, gcc toolchain with latest or at least very recent versions in order to use c++11 support in latest gcc, and ld.gold in recent binutils, and possibly improvements in recent glibc.
I want to put the whole toolchain in some separate directory, and not to influence any existing system files. I also want to build gcc with --sys-root so that when using the gcc, I don't need to specify -I/some/directory/include and -L/some/directory/lib or whatever other parameters. Also the generated executable will automatically use the new ld-linux-xxxxx program loader which will automatically find the new libc.so.
Anyone knows if there exists some tutorial on this task?
The compiler is very dependent on glibc, altough you manage to build the compiler either in a chrooted system or equivalent, you will need to build also all libraries needed with the program you will build with this new compiler.
The best you can do is use a fresh new system (vm or whatever) or upgrade your existing one
You can download the latest toolchain from Openembedded or Yocto.
And here you don't have to do any package installation to your current system.
Just download the toolchain, source the environment and thats it you are ready to check the c++11 support.
The location to download the toolchain:
http://downloads.yoctoproject.org/releases/yocto/yocto-1.7/toolchain/ (Just select the architecture either 32bit or 64 bit based on your machine support)
If you need the latest toolchain, you'd better migrate to Fedora.
If you can't/won't, the best bet is to get the pieces as source RPMs for CentOS and Fedora, unpack them and fix up the CentOS by pilfering the sources and patches from Fedora, take care it doesn't overrule the system packages, correct versions and fix to install elsewhere (don't mess up your system too much! /usr/local comes to mind). The pieces are at least binutils, gcc.
I do not knwo Why you need this ? If this is needed that to compile for another computer, I would suggest using a virtual machine running the same OS as target. much more easier !!
In the PSPSDK (Homebrew) we are using the Binutils 2.16.1 to assemble and link the code for the PlayStation Portable, however that release is getting quite outdated (3 versions have superseded it). The community and me have been updating the GCC and newlib to the latest stable versions and everything seems to work with the old binutils.
Will GCC produce better code with binutils 2.19? Why?
Will binutils 2.19 produce better elf files and libs than 2.16.1? Why?
binutils 2.19 has a new ELF linker called gold which is multi-threaded, written in modern C++, and quite a bit faster than the usual ld linker. I'm not sure however about the work involved to adapt it.
Other than that, well new versions always are a good idea. Performance and bug fixes are likely to have been included, of course. I think i would certainly try it and if something goes wrong you can still backstep.
In general, you don't need to upgrade binutils unless you run into some bug fixed in a later binutils version, or need new features (such as linker build-ids).
In particular, GCC code generation is largely independent of binutils (except for constructs like __thread, which require certain level of support from binutils).