Thread: Gimp

Welcome to GCC
First of all. of course, you must write code that is platform independent, i.e. that uses instructions that can be reproduced in any operating system. As long as you write software using functions defined in the standard C library, minus POSIX functions (such asfork()), you are fine. It'll build. You can go to a GNU machine and pass your file through GCC to get a Linux binary. then go to a Windows box and pass it through VC++ to get a Windows binary.

Now, as you move to large programs (such as The GIMP). you will need multiple source code files to produce a single binary. This will result in problems, because you cannot just build the files at one go. You will need to compile your C sources into the assembler. then assemble them into object files, put all the object files together in a single object archive and then link that archive to the system libraries. The answer to this problem is Makifiles, which can do all that automatically accordi ng to a set of rules applied to a set of files. But even Makifiles have their limitations, and Makifiles written for GNU Make are not compatible with Microsoft MAKE and a Makifile written to use GCC cannot use VC++, and vice versa.

The answer to this problem is to use something called a retargetable compiler, or a compiler that can produce binaries for different operating systems. Fortunately for us, GCC is retargetable. And unfortunately for us. GCC must be re-built before it can produce Win32 or Win64 code.

GCC cannot work on its own - it is part program, and partly a wrapper around other programs. To build a working toolchain, we need two packages -- GCC itself and GNU Binutils.

All that GCC does by itself is convert high-level source code into an assembler. GCC includes compilers for C, C++, ADA, Fortran, Objective C, Objective C++ and Java. BarringJava, which is interpreted, all other languages need their programs to be converted into binaries. To explain how this is done, let us do it manually from the command line.

So what now?
Now that we know all about what GCC and the tools from Binutils do, we produce C. GCC converts it to assembly. GAS converts that to a binary and LD links them to the libraries. Now C is high level, and the same C sources can be built on all C compilers. But the assembler is not, and the binaries are absolutely not.

What we need to do is build a version of the GNU toolchain that is capable of producing code meant for execution in Windows.

Enter MinGW32
Binaries also have certain formats. Linux uses the Executable Linkable Format (ELF) binaries. Windows, on the other hand, uses Common Object File Format (COFF) binaries, or technically, a variant of COFF, which is known as Windows PE (Portable Executable). PE files can store executable code, as well as all the resources needed to use that code (that is, pixmaps, icons, audio, animations and what not) all by itself GCC could always produce COFF binaries, so it was a simple task of patching a few lines of code to make it produce PE files.

GCC versions post v2.95 could produce PE format binaries. With this hurdle cleared, all that remained was a C Runtime Library that would be able to 'support applications in Windows. A C Runtime Library (CRT) is' the library that provides the standard header files and the LibC library. The MinGW Project was thus created, and it published two packages: a CRT that was linked against MSVCRT.DLL, or Microsoft's own C runtime library, and an (incomplete but substantial, enough for compiling GNU software) implementation of the Win32API (the Windows Platform SDK headers and libraries) for GCC.

What we are going to do now is build a version of GCC that will produce Win32 binaries.

Downloads
We need to get some source packages: GCC itself, GNU Binutils, w32api and mingwrt. Here are the download links:
-Win32API: Browse MinGW - Minimalist GNU for Windows Files on SourceForge.net / w32api-3. 13-mingw32-src. tar.gz
-MinGW Runtime: http://nchc.dl.sourceforge.net/sourceforge/ mingw/mingwrt -3. 15.2-mingw32-src. tar.gz
-GNU Binutils (Latest snapshot. because release version is broken): http://sources-redhatmirrors.airband.net/binutils/ snapshots/binutils. weekly tar.bz2
-GCC 4.4.0 (Yeah, it's been released!): http://ftp.gnu.orglpub/ gnu/ gcc/gcc-4. 4. 0/ gcc-4. 4. O. tar. bz2
GMP: http://ftp.gnu.orglgnu/gmp/gmp-4.3.1.tar.bz2
-MPFR: http://www.mPfr.orgimpfr-current/mPfr-2.4.1.tar.bz2

Building

It's safest to install something like a compiler to its own prefix, to keep it from mixing up with and fouling up the distro compilers. We will install our copy of the MinGW Cross Compilers to /opt/mingw.

The last command added the MinGW compilers' bin directory to the PATH variable. Do not exit the terminal. If you do, you'll have to type in the export command again. We'll take care of this later.

Now we need to clean the build directory, and copy the MinGW headers required to build GCC.

That soft link is required for building the runtime. Now it's time to build GCC. GCC needs to be built in two parts, first a basic C compiler, and then a full set of compilers for all languages.

GMP is often miscompiled. But there's nothing that can be done about it, as GMP will be built within GCC itself. To check, you can build GMP and then run a make check on it. If you find problems that can be corrected, you'll have to edit the source code yourself.

That was the basic compiler build. Notice the use of sudo in all the three commands required to build GCC-this is because GCC insists on changing the directory structure in /opt/mingw in the configure step itself, and since the makefiles have superuser permissions, we need to have root privileges to do the make and make install. Also note that we've disabled shared library building; this needs a file called dllcrt.o which is part of the MinGW runtime and hasn't been built yet.
We now need to build our C Runtime Library, the Win32APl library and the actual build ofGCe. First. the runtimes:
That's it! You have a fully working C, c++ and Formula Translator compiler toolchain that'll compile code meant to run on Windowsl

More
MinGW does not provide a POSLX implementation, so you are out ofJuck on compiling programs that rely on POSLX functions, Not many do, and most that do, have an alternative set of sources meant to use the Win32API to replace POSLX calls by native Win32 ones, But once in a while, if you need POSIXAPI support, Google for Cygwin and download what's required. Beware though, Cygwin doesn't come as a cross-compiler and it's terribly difficult to build one. Cygwin requires Windows NT 5 and above to run.

(NT 5 is Windows 2000. XP is NT 5.1, and Windows Server 2003 is NT 5,2, as is Windows XP Professional x64 Edition, Vista and Server 2008 are NT 6, and Windows
7 and Server 2008 R2 are NT 6,1. This information will help when you want to develop a program meant to run only on certain versions of Windows, as internally, all Windows OSs 'know' themselves by their NT version numbers and not their names.)
But hey ...
..we just built a cross-compiler, so how do we use it? It can be made difficult, and then it can be made simple. Actually, all you need are some environment variables. Here goes:

The first step is adding the path /opt/mingw/bin to your PATH variable. Type in the export command that we executed after building Binutils.

The second step is configuring the source with a "..host=i686-pc-mingw32" flag.

That's all.
There's one final thing to do before signing off: testing the Gee compilers. I don't know any Fortran, so I could never test Fortran; however quite a lot of GNU Projects insist on having some version of Fortran in the tooJchain, so its a safe bet to keep it built. We need to test the compilers in a "Hello World" program. For C, you can use the one in the example src.c file in the previous page; for c++ the program goes somewhat like compile both the files with:

Here are the results of a comprehensive testing of both Binutils and GCC Components. Oh wait, I exaggerated;-):

There you go! One boxed Ploduct, ready to run' Now I gotta go build myself a version of libVLC. Bye ...