If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Yesterday's release of gcc, version 4.3.0, was a shock. The compilation of the Fortran compiler failed. The compilation of the Win32 (mingw32) cross compiler failed. This was incredibly shoddy for a major release. I imagined people having significant problems figuring what was going on, so, I wrote this article to try and help out. Of course, in this article, I will not use version 4.3.0, but its immediate predecessor, version 4.2.3.

Well, it turns out that both of these problems go away, if you do the build in directories separate from the sources. Since this is non-traditional, it might have been nice for people to point out that the build will not work, in certain cases, unless you build in separate directories. For projects like gcc, compiling in separate directories is actually a great idea.

Although the original problems with 4.3.0 have been solved, I ran into more difficulties later in the program, so, at least for the time being, I have stuck with version 4.2.3. Below, I have repeated the original program using separate build directories. If you do this, all the compilers and cross-compilers, are able to compile, at least, C, C++, Fortran and Java code. I made no attempt to incorporate ADA into the mix.

This is an outline of what we will do:

(1) compile a C,C++,Java,Fortran,ObjC,ObjC++,treelang compiler for Linux(2) compile a C cross-compiler for Linux (needed to compile system libraries)(3) compile a C,C++,Java,Fortran,ObjC,ObjC++ cross-compiler for Linux(4) compile a C,C++,Java,Fortran,ObjC,ObjC++ compiler for Windows(5) compile a C,C++,Java,Fortran cross-compiler for Windows

Compiler (1) runs on a Linux box and produces binaries that will run under Linux
Compiler (3) runs on a Linux box and produces binaries that will run under Windows
Compiler (4) runs on a Windows box and produces binaries that will run under Windows
Compiler (5) runs on a Windows box and produces binaries that will run under Linux

I have recently added some extra sections:

(6) How to use the Cross-Compiler(s) you built in step 3.(7) Adding the language ADA to the mix.(8) Using the Compiler(s) you built in step 1.(9) General Remarks.

Make sure that you have the following programs and packages installed.

We do this to have an up-to-date compiler (actually, a collection of compilers) with which to compile the cross-compilers of steps 2 and 3. Beginning with an older compiler can lead to some complications. I did the build on a SuSE 10.0 Linux box. Using the installed compiler (version 4.0.2) worked for all steps except parts of (4) and all of (5). Using version 4.2.3 means that most things work.

Save all the packages to the directory /gcc/. Go there and unpack everything:

cd /gcc/binutils-linux-linux
/gcc/binutils-2.18.50/configure
make
make install

Code:

cd /gcc; mkdir gmp-linux gmp-win32

Code:

cd /gcc/gmp-linux
/gcc/gmp-4.2.2/configure
make
make install

The make install script runs the command ldconfig -n /usr/local/lib. It turns out that this is not sufficient, you need to run ldconfig (as root). This updates the ld.so.cache file so that it knows to use the newly installed gmp library, rather than some older, pre-existing, gmp library. In particular, you want the compilation of the mpfr library to use the correct version of gmp.

Code:

ldconfig

Code:

cd /gcc; mkdir mpfr-linux mpfr-win32

Code:

cd /gcc/mpfr-linux
/gcc/mpfr-2.3.1/configure
make
make install

Similarly, if you have some pre-existing version of the mpfr library, then you need to run ldconfig again. You should probably run ldconfig again, in any case, just to be on the safe side.

So that version 4.2.3 does not interfere with your older installed compiler, it will be installed in /usr/local/. To use it, instead of the installed compiler, you need to have /usr/local/bin first on your path. You arrange this with:

Code:

export PATH=/usr/local/bin:$PATH; echo $PATH

(2) Compile a C cross-compiler for Linux.

This C cross-compiler will run on your Linux system and create binaries, from Linux C code, that will run on a Windows system. We need to use this cross-compiler to compile the Win32 API and runtime libraries.

The C cross-compiler is compiled again, along with the other languages. This cross-compiler is run on your Linux box and compiles binaries, from Linux code, that will run on a Windows system. That is, it compiles Linux source code, so that the resulting binaries will run, unaltered, on Windows.

This compiler is a native Windows compiler. That is, it runs on a Windows box. It compiles Windows source code and the resulting binaries will run on Windows. When compiling C++, this compiler will do the same job as Visual C++ or C++ Builder.

Code:

export CC="i686-pc-mingw32-gcc"; echo $CC

Code:

mkdir /mingw
cp -r /usr/local/i686-pc-mingw32/{include,lib} /mingw

The configure script expects to find the system headers and libraries in /mingw, so we have arranged for them to be there.

The reason for the second installs into /mingw, is that the libtool libraries, i.e., the .la files, have their destination directory hard-coded into them, so you can not simply copy them from /usr/local/i686-pc-mingw32/lib to /mingw/lib.

The files that end up in /mingw will be transfered to C:\mingw on your Windows box.

This compiler runs on a Windows box. It compiles Windows source code and the resulting binaries will run unaltered on Linux. Ever wanted to compile VirtualDub so that it runs on Linux? This avoids having to port the source code.

Now you copy everything in /mingw to C:\mingw on a Windows box and start compiling there. After you have compiled your Windows program, say VirtualDub, on your Windows computer, you transfer the resulting executable back to Linux and run it there. Of course, for most compilations you will also need to compile a version of the make program for Windows. You can compile the make program for Windows, on your Linux box, by using the cross-compiler you built in step (3).

(6) How to use the cross-compiler you built in step 3.

As a quick example of how to use the cross-compiler you built in step 3. Download the Linux make program to /gcc/:

Then reset you PATH variable and continue from section (2), as above, except adding ada to the --enable-languages option.

Code:

export PATH=/usr/local/bin:$PATH; echo $PATH

You could also try the compiler in gnat-gpl-2007-i686-gnu-linux-libc2.3-bin.tar.gz (75M) from libre.adacore.com. Unfortunately, gcc-4.2.3 does not compile at all and gcc-4.3.0 does not compile outside the sources.

If at any time you need to know which compiler you are using, just enter the command:

I actually used x86_64-pc-linux-gnu and am assuming that x86_64-linux-gnu will work.

If you have a multilib system, like Debian, you may want to compile both 32-bit and 64-bit libraries for gcc. You need to have all the standard 32-bit libraries installed. On Debian, make sure you have the links:

The compilation will fail, for gcc-4.2.3, unless you use the --disable-multilib configuration option, or you create the (secret) link:

Code:

ln -s /emul/ia32-linux/lib /usr/local/x86_64-pc-linux-gnu/lib/32

For gcc-4.3.0 the above link appears to be unnecessary (4.3.0 has other problems).

I have been running short on space and over time have deleted all my Windows partitions. As soon as I get around to reinstalling Windows, I will let you know how the Windows compilers work. I have now done this. There are weird problems with the Fortran compiler and the Java Virtual Machine, gij, is mysteriously missing. C C++ ObjC and ObjC++ seem OK, at least for simple programs. The compilers were run from an XP cmd window. I only looked at the native Windows compilers. I will look at the cross compilers at some later date.

By the way, if you wish to both watch, and record, the output of the compilation, you can do this:

Comment

Well, it turns out that both of these problems go away, if you do the build in directories separate from the sources. Since this is non-traditional, it might have been nice for people to point out that the build will not work, in certain cases, unless you build in separate directories.

Building outside the tree has been standard practice with GCC for as long as I can remember, and is pretty clearly noted in the install instructions:

First, we highly recommend that GCC be built into a separate directory than the sources which does not reside within the source tree. This is how we generally build GCC; building where srcdir == objdir should still work, but doesn't get extensive testing; building where objdir is a subdirectory of srcdir is unsupported.

Granted, the srcdir = objdir case should work, and it's not as though GCC is ideal in any case. A wise man once said: "gcc is the holy cow of compilers, not the holy grail".

Comment

As noted above, some things, like the WINDOWS Java compiler, don't really work with 4.2.3. Although the WINDOWS Java compiler compiles, many ancillary programs and libraries, like the Java Virtual Machine, gij, are missing. To compile these, one needs to add the configuration option --enable-libgcj, to part 3, giving: