So: The GNU Ada project needs help.
What went wrong
>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:
- The Cygwin based compiler fails 21 ACATS tests while the same Linux version passes them all.
- 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.
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 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=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 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=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 :-( .
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 http://rmathew.com/articles/gcj/bldgcj.html as a reference. Having said that, it looks like GCC is pretty broken right now in the area of MINGW for all languages as http://gcc.gnu.org/ml/gcc/2006-04/msg00441.html 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.