Intended audience: developers.

Help needed.

That we have not yet packaged a complete MS-Windows toolchain of GNAT is not because we have not tried. We have tried and it did not work as well as we would have liked.

So: The GNU Ada project needs help.

What went wrong

GNAT is part of the GNU Compiler Collection. There is currently no native port of GCC for MS-Windows. One has to choose one of two available APIs for MS-Windows. Both have their specific problems.


Cygwin provides a more or less complete POSIX interface on top of Windows. It is the more advanced Unix emulation that comes with the more modern and complete toolchain:

 >bash --version
 GNU bash, version 3.00.16(14)-release (i686-pc-cygwin)
 Copyright (C) 2004 Free Software Foundation, Inc.
 >/bin/vi --help
 VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Dec 18 2005 16:00:54)
 >automake --version
 automake (GNU automake) 1.9.6
 >make --version
 GNU Make 3.80
 Copyright (C) 2002  Free Software Foundation, Inc.
 >makeinfo --version
 makeinfo (GNU texinfo) 4.8

As such it was quite easy to produce a GNAT compiler for Cygwin, only minor changes to the RPM Package Manager specifications were needed. However the resulting compiler is missing some important funtionality:

  1. The Cygwin based compiler fails 21 ACATS tests while the same Linux version passes them all.
  2. The Cygwin based compiler can't create DLLs using the GNAT project manager.

GNAT had never been officially ported to the Cygwin environment. That mainly affects the tasking support, but also the library manager. Hence the two observed failures above.

Especialy the DLL part is very problematic since almost all current Ada libraries make Shared Librarys most of which use the GNAT project manager. On Cygwin it might be possible to create Unix like dynamic .so libraries, though.


MinGW provides a minimal environment to run gcc on Windows. It is not intended to provide a POSIX envronment rather it provides the native MS-Windows environment to gcc. It is far not as modern then Cygwin and comes with a smaller and outdated toolchain:

 >bash --version
 GNU bash, version 2.04.0(1)-release (i686-pc-msys)
 Copyright 1999 Free Software Foundation, Inc.
 >/bin/vi --help
 VIM - Vi IMproved 5.8 (2001 May 31, compiled Jan 15 2002 14:14:20)
 >automake --version
 automake (GNU automake) 1.8.2
 > make.exe --version
 GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
 Built for i686-pc-msys
 Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000
 >makeinfo --version
 makeinfo (GNU texinfo) 4.3

Apart from some minor anoyances like a missing RPM Package Manager and no Subversion the main problem is: MinGW can't compile the gcc 4.1.0 at all.

make trouble

The fist problem came from the make tool. There are actually two version available with MinGW, which both produce a different error:

make 3.79.1
Terminates the compilation with an error message.
make 3.80.0
Goes into an endless recursion. The MinGW team states that this version of make is indeed unsuitable for the use with automake toolchain.
Update 1
We solved the make problem - automake created an over complex searchpath to find "ld.exe" and make stumbled over it. We solved this by providing §c§export LD=...§. This is gcc bug PR24382.

However: MinGW outdated makeinfo fails now to create the gnat texinfo files. See the gcc bug report PR 20822 ( for a patch that solves this problem.

This way it is possible to bootstrap the compiler itself. But when the build process starts compiling the run time system, it cannot find the assembler anymore. This is gcc PR 27043 (

Note that it is unclear if this should be a GCC bug report or a MINGW report. The issue clearly seems to be related to the passing of the -B../.. flag to the xgcc that is being used at this point in the build. Even a simple command line call of xgcc from the ada/rts directory resuls in this error if -B is specfied and does not if -B is not specified. The AS that xgcc is being told to use here is a bourne shell script that calls the real assembler.

It looks as though the compiler simply does not believe there is an executable file in ../.. called as probably because it is using win32 rules about things that can be executed (i.e. BAT files, exe files, etc). Either way, I don't see an simple fix for it.

Update 2
I reinstalled MinGW folowing the instructions more closely then the first time. But that made it worse :-( .

Cross compilation

As an alternative we have successfuly tried to cross compile GCC for MingGW both with Cygwin or with Linux. This version is ready for download and testing. We hope to use the cross compiler to create a native MinGW compiler.

Update 3

It seems like Cross compiliation will probably be the best way to go and perhaps we can use as a reference. Having said that, it looks like GCC is pretty broken right now in the area of MINGW for all languages as in the GCC develops mailing list points out.

Perhaps by keeping on eye on this thread we can leverage any solutions they come up with.

Ada for .NET

While not currently managed as part of the GNUAda project, it is worth pointing out that Ada is available for .NET and it even includes integration with Visual Studio.

Ada programming, © 2005,2006 the Authors, Content is available under GNU Free Documentation License.