I have some limited experience building gcc/gnat on Windows using the MinGW environment. I did so on a regular basis for the 3.2, 3.3, and 3.4 branches and compared the ACATS results at different optimization levels. I'll try to build 4.1.0 in a few minutes and I shall report my experience here.
Building gcc on Mingw used to require some specific patches to the gcc sources. gcc-3.x did not compile out of the box. These patches are developed and contributed to the FSF sources by the mingw maintainers on a regular basis. What is your politics here at gnuada? Do you develop your own pathces of the different packages or do you distribute only binaries built from vanilla sources?
Rolf
BTW, it is not that hard to set up a working MSYS/MinGW as the wiki pages suggest. Following the instructions on mingw.org works for most people...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
tasm32 doesn't want to assemble the result however. Maybe masm or yasm?
Another question :
Currently gnat for mingw is compiled from Cygwin. What about an Interix version? Interix is not a layer, it is full featured POSIX subsystem. SFU is available for free, Vista seem to come with SUA preinstalled. I think we'll have less problems if we switch to Microsoft's supported way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It would be very helpfull if you could contribute an MinGW port. For that I add you to the developer list.
As for patches: We do what is needed.
I think it is very important that everything can be reproduces as we are all voluntees are may suddenly not have the time any more to continue. In this case somebody else must be able to pick up where I left.
For that I allways try to automate the process. Extract (vanilla sources) - patch (if needed) - configure - compile - test (if possible) - package (binary and source). One script does it all. Of corse rpm helps here as rpmbuild does precisly that. I wonder if rpm can be compiled for MinGW.
You might want to check out the Subversion archive to see how we do it.
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I finally managed to build gcc-4.1.0 on MinGW with some fiddling in the Makefiles and manual copying ld and as. Unfortunatly I cannot make the testsuite compile. It already fails to link one of the support programs. I therefor doubt that the current version would be of any use to anybody.
MK> You might want to check out the Subversion
MK> archive to see how we do it.
I had a look at the files in the subversion repository. I don't see at all how you do it (probably due to my unwillingness to understand RPM scripts)
Rolf
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What if we replace the "as.exe" and "ld.exe" with frontends to Microsoft (or Borland) Assembler and Linker ?
Benefits :
Native windows builds
Ready to Win64 (Microsoft already has Win64 compiler, Borland are to produce it later)
Interoperability with another compilers
(mixing Delphi and Ada is very hard to do, but it is very attractive)
Problems :
C/C++ runtime exists in Microsoft and Borland except some APIs, while GNAT runtime seems to need to be patched more
GAS and MASM/TASM have different syntax, we need reliable conversion tool. There is a tool named "Intel2GAS".
Intel2GAS uses customizable templates, and even capable of reverse conversion.
But reverse tables are not so good. I've tryed to feed a listing of "procedure ... is null;" program to the Intel2GAS but it didn't understood all the directives. Reverse tables probably may be improved.
I think it's interesting.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) So far, this project has been limited to Ada specific packaging of existing tool suites and we have not demonstrated the manpower to really take on more. So (for example) some of what you are proposing would really need to be looked at by the mingw group.
2) It is not clear that your proposal actually would achieve the ends that you are talking about. Switching to a different backend assembler/linker does not seem likely yo result in win64 code. It is a little further back in the compiler where this would need to happen.
3) Not really clear what you mean by native windows builds either as the GNAT based on mingw is pretty darn native.
4) Not entirely clear that switching the as/ld would help with Delphi/Ada integration. Can you describe how it helps?
5) I really have no idea what "GNAT runtime seems to need to be patched more" is trying to say. I am not arguing with the statement. I just don't know what you mean.
I would think that these days, that seamless windows integration would mean integration with something like visual studio .Net and generating code for the .NET CLR. This already exists (http://asharp.martincarlisle.com/)
I am not sure if I am missing what you are trying to say or if you are going after a goal based on incorrect assumptions.
I do agree however that the root desire of your concepts are interesting.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
2) GCC is capable of generating x86_64 code for Linux, for example. I don't know how much do the conventions of x86_64 calling/register saving differ in Windows and NIXes, but it's a chance. Mingw and Cygwin are still 32bit, and IMHO it will take more time to implement full support of amd64 arch.
3) Mingw and Cygwin provide an implemented POSIX layer. Microsoft/Borland C/C++ runtimes of course targetting Win32 by definition. If some C/C++ program is not using POSIX-specific API, it can be compiled with GCC and linked with Microsoft/Borland native runtimes.
4) A few years ago there was only one object file format on Windows : OMF (I'm not talking about GCC now)
Let's call it Intel OMF.
Then 2 general compiler vendors (Borland and Microsoft) changed their object file formats to "Borland OMF" and COFF respectivelly. Mingw is capable of emitting COFF object files only (not counting ELF). So if I need to use GCC and DCC32 together I must find "a common point". And it's better to feed DCC32 with GCC's ready object files. Compiling Delphi units to OBJect files is possible but not recommended. I have found 2 utilities to make a conversion :
GCC produces COFF
COFF -COFF2OMF-> Intel OMF -OMF2D-> Borland OMF
(There are 2 COFF2OMF utilities and I mean not the Borland's one. Borland COFF2OMF is intended for '.lib's interfacing some '.dll'(-s). Right one can be found in the Digital Mars toolchain and somewhere else for free)
My scheme didn't succeed. Resulting '.obj's have no name table. This scheme seems to work properly when mixing Microsoft and Borland. I don't know where is the problem. May be it's a remangling problem. I've given up this idea.
As for me it is simpler to make earth and sky meet in the assembler phase. At least it can be observed better.
Native interface builders definitelly dominate over the crossplatform ones. I mean if somebody want to make really perfect, but crossplatform program one must use MSVS/BDS on Windows, XCode on Mac and something another on Linux to make the platform-dependent interface parts. C/C++ programmers have this possibility, while Ada support lacks on Windows yet.
5) I mean "GNAT runtimes target POSIX". Some code can be rewritten exclusivelly for Windows.
However I didn't check this.
Anyway thanks for your attention.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have some limited experience building gcc/gnat on Windows using the MinGW environment. I did so on a regular basis for the 3.2, 3.3, and 3.4 branches and compared the ACATS results at different optimization levels. I'll try to build 4.1.0 in a few minutes and I shall report my experience here.
Building gcc on Mingw used to require some specific patches to the gcc sources. gcc-3.x did not compile out of the box. These patches are developed and contributed to the FSF sources by the mingw maintainers on a regular basis. What is your politics here at gnuada? Do you develop your own pathces of the different packages or do you distribute only binaries built from vanilla sources?
Rolf
BTW, it is not that hard to set up a working MSYS/MinGW as the wiki pages suggest. Following the instructions on mingw.org works for most people...
Found :
gcc can produce Intel-syntax asm-listings
gcc -masm=intel
tasm32 doesn't want to assemble the result however. Maybe masm or yasm?
Another question :
Currently gnat for mingw is compiled from Cygwin. What about an Interix version? Interix is not a layer, it is full featured POSIX subsystem. SFU is available for free, Vista seem to come with SUA preinstalled. I think we'll have less problems if we switch to Microsoft's supported way.
It would be very helpfull if you could contribute an MinGW port. For that I add you to the developer list.
As for patches: We do what is needed.
I think it is very important that everything can be reproduces as we are all voluntees are may suddenly not have the time any more to continue. In this case somebody else must be able to pick up where I left.
For that I allways try to automate the process. Extract (vanilla sources) - patch (if needed) - configure - compile - test (if possible) - package (binary and source). One script does it all. Of corse rpm helps here as rpmbuild does precisly that. I wonder if rpm can be compiled for MinGW.
You might want to check out the Subversion archive to see how we do it.
Martin
I finally managed to build gcc-4.1.0 on MinGW with some fiddling in the Makefiles and manual copying ld and as. Unfortunatly I cannot make the testsuite compile. It already fails to link one of the support programs. I therefor doubt that the current version would be of any use to anybody.
MK> You might want to check out the Subversion
MK> archive to see how we do it.
I had a look at the files in the subversion repository. I don't see at all how you do it (probably due to my unwillingness to understand RPM scripts)
Rolf
Super. I just given up. However - since you got further then I there might be hope after all.
RE> I don't see at all how you do it
RE> (probably due to my unwillingness to
RE> understand RPM scripts)
Actualy native MinGW is not done by RPM Scripts. It is done by the follwing scripts:
tar/configure/gnat-gcc-4.1.0.bash
tar/configure/rpmbuild.bash
rpm/SPECS/common.bash
rpm/SPECS/gnat-common.bash
Even true two scripts are in the rpm tree they realy are all bash only.
The MinGW rpm specs are for cross compilations. But cross compilations fail on linking the target libraries.
Martin
What if we replace the "as.exe" and "ld.exe" with frontends to Microsoft (or Borland) Assembler and Linker ?
Benefits :
Native windows builds
Ready to Win64 (Microsoft already has Win64 compiler, Borland are to produce it later)
Interoperability with another compilers
(mixing Delphi and Ada is very hard to do, but it is very attractive)
Problems :
C/C++ runtime exists in Microsoft and Borland except some APIs, while GNAT runtime seems to need to be patched more
GAS and MASM/TASM have different syntax, we need reliable conversion tool. There is a tool named "Intel2GAS".
Intel2GAS uses customizable templates, and even capable of reverse conversion.
But reverse tables are not so good. I've tryed to feed a listing of "procedure ... is null;" program to the Intel2GAS but it didn't understood all the directives. Reverse tables probably may be improved.
I think it's interesting.
A few issues.
1) So far, this project has been limited to Ada specific packaging of existing tool suites and we have not demonstrated the manpower to really take on more. So (for example) some of what you are proposing would really need to be looked at by the mingw group.
2) It is not clear that your proposal actually would achieve the ends that you are talking about. Switching to a different backend assembler/linker does not seem likely yo result in win64 code. It is a little further back in the compiler where this would need to happen.
3) Not really clear what you mean by native windows builds either as the GNAT based on mingw is pretty darn native.
4) Not entirely clear that switching the as/ld would help with Delphi/Ada integration. Can you describe how it helps?
5) I really have no idea what "GNAT runtime seems to need to be patched more" is trying to say. I am not arguing with the statement. I just don't know what you mean.
I would think that these days, that seamless windows integration would mean integration with something like visual studio .Net and generating code for the .NET CLR. This already exists (http://asharp.martincarlisle.com/)
I am not sure if I am missing what you are trying to say or if you are going after a goal based on incorrect assumptions.
I do agree however that the root desire of your concepts are interesting.
2) GCC is capable of generating x86_64 code for Linux, for example. I don't know how much do the conventions of x86_64 calling/register saving differ in Windows and NIXes, but it's a chance. Mingw and Cygwin are still 32bit, and IMHO it will take more time to implement full support of amd64 arch.
3) Mingw and Cygwin provide an implemented POSIX layer. Microsoft/Borland C/C++ runtimes of course targetting Win32 by definition. If some C/C++ program is not using POSIX-specific API, it can be compiled with GCC and linked with Microsoft/Borland native runtimes.
4) A few years ago there was only one object file format on Windows : OMF (I'm not talking about GCC now)
Let's call it Intel OMF.
Then 2 general compiler vendors (Borland and Microsoft) changed their object file formats to "Borland OMF" and COFF respectivelly. Mingw is capable of emitting COFF object files only (not counting ELF). So if I need to use GCC and DCC32 together I must find "a common point". And it's better to feed DCC32 with GCC's ready object files. Compiling Delphi units to OBJect files is possible but not recommended. I have found 2 utilities to make a conversion :
GCC produces COFF
COFF -COFF2OMF-> Intel OMF -OMF2D-> Borland OMF
(There are 2 COFF2OMF utilities and I mean not the Borland's one. Borland COFF2OMF is intended for '.lib's interfacing some '.dll'(-s). Right one can be found in the Digital Mars toolchain and somewhere else for free)
My scheme didn't succeed. Resulting '.obj's have no name table. This scheme seems to work properly when mixing Microsoft and Borland. I don't know where is the problem. May be it's a remangling problem. I've given up this idea.
As for me it is simpler to make earth and sky meet in the assembler phase. At least it can be observed better.
Native interface builders definitelly dominate over the crossplatform ones. I mean if somebody want to make really perfect, but crossplatform program one must use MSVS/BDS on Windows, XCode on Mac and something another on Linux to make the platform-dependent interface parts. C/C++ programmers have this possibility, while Ada support lacks on Windows yet.
5) I mean "GNAT runtimes target POSIX". Some code can be rewritten exclusivelly for Windows.
However I didn't check this.
Anyway thanks for your attention.