To my surprise and joy, I managed to build a Mac OS X hosted cross compiler targeting Windows (MingW).
I used the information found at (or through) http://www.mingw.org/mingwfaq.shtml, more specifically http://www.libsdl.org/extras/win32/cross/README.txt. With some necessary modifications, the http://www.libsdl.org/extras/win32/cross/build-cross.sh script was able to build cross binutils, as well as gcc and gpc cross compilers.
The actual build was done with gpc 20041017 and gcc-3.3.3-200402017-1 (mingw special).
I hope, I will find time (in a few weeks) to add binaries, sources and a build script for the cross compiler to my website.
The cross compiler swallows hello.pas and the resulting binary actually does say "Hello, World" at the other side of the fence. However, the question arises how reliable the cross-compiler is, as the testsuite says "if this is a cross-compiler, you can't run the test suite easily". Is it reasonable to rely on native testsuite results on both the host and the target ?
Regards,
Adriaan van Os
On 26 Oct 2004 at 0:05, Adriaan van Os wrote:
To my surprise and joy, I managed to build a Mac OS X hosted cross compiler targeting Windows (MingW).
I used the information found at (or through) http://www.mingw.org/mingwfaq.shtml, more specifically http://www.libsdl.org/extras/win32/cross/README.txt. With some necessary modifications, the http://www.libsdl.org/extras/win32/cross/build-cross.sh script was able to build cross binutils, as well as gcc and gpc cross compilers.
The actual build was done with gpc 20041017 and gcc-3.3.3-200402017-1 (mingw special).
With Mingw, you'd be advised to stick with gcc-3.2.3 until the predefines issue is sorted out.
I hope, I will find time (in a few weeks) to add binaries, sources and a build script for the cross compiler to my website.
The cross compiler swallows hello.pas and the resulting binary actually does say "Hello, World" at the other side of the fence. However, the question arises how reliable the cross-compiler is, as the testsuite says "if this is a cross-compiler, you can't run the test suite easily".
AFAICS you can only build a Mingw GNU compiler with a cross compiler. Even the Mingw-MSYS environment is a cross compiler, since, it is simply a fork of the Cygwin project, relies on a (large) DLL to provide the POSIX emulation, and has its own "native" binaries (i.e., that rely on the DLL). So whether a cross-compiler is reliable or not depends on which cross compiler. Some (e.g., MSYS) are reliable, and I am sure that there are some that are not.
Is it reasonable to rely on native testsuite results on both the host and the target ?
AFAIK you cannot run a "native" Mingw testsuite, since the testsuite (from what I can see - I may be wrong) requires at least (ba)sh and one or two things, for which there are no native Windows versions that can hack it.
As far as "cross compilers" go, I once handcrafted one for building Mingw compilers (simple job of replacing the files in the 'include' and 'lib' directories, and 'libgcc.a' and such, with the Mingw versions. Worked like a dream - and it only took me a few minutes to achieve. Maybe it was so easy because it was a Cygwin toolchain that I emasculated so - but I doubt it.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.greatchief.plus.com/
Prof. A Olowofoyeku (The African Chief) wrote:
With Mingw, you'd be advised to stick with gcc-3.2.3 until the predefines issue is sorted out.
I started out with gcc-3.2.3-20030504-1-src.tar.gz, but the tar file is apparently corrupt. I posted a message about that to mingw-users@lists.sf.net.
AFAICS you can only build a Mingw GNU compiler with a cross compiler. Even the Mingw-MSYS environment is a cross compiler, since, it is simply a fork of the Cygwin project, relies on a (large) DLL to provide the POSIX emulation, and has its own "native" binaries (i.e., that rely on the DLL).
In this context, I mean with a "cross compiler" a compiler where host and target are running on different hardware and operating systems. I do understand about the POSIX emulation DLL. I think there are two issues:
- the compiler using the POSIX emulation DLL for its operation. However, this doesn't apply to a cross-compiler hosted on a OS with a POSIX compatible UNIX kernel, like Linux or Mac OS X (and many others). Actually, this suggests that a Win32 targeted cross-compiler running on a UNIX host is more stable than one running under POSIX emulation on Wintel itself. - runtime library code, using POSIX calls rather than "native" Win32 calls, e.g. ReadLn using "read" rather than "ReadFile". If the POSIX emulation DLL isn't stable or 100 % compatible (I really don't know) I think there are two ways out (a) adapt the RTS to use Win32 calls (b) use Win32 calls instead of the RTS at the application level.
So whether a cross-compiler is reliable or not depends on which cross compiler. Some (e.g., MSYS) are reliable, and I am sure that there are some that are not.
How compatible, stable and fast is the RTS, as compared to "native" Win32 calls ?
Is it reasonable to rely on native testsuite results on both the host and the target ?
AFAIK you cannot run a "native" Mingw testsuite, since the testsuite (from what I can see - I may be wrong) requires at least (ba)sh and one or two things, for which there are no native Windows versions that can hack it.
Yeah, but you could run the testsuite on a Wintel machine under MingW. Or compile the testsuite on the host machine to a "programs" directory, transfer it to the target machine and then run the executables there.
As far as "cross compilers" go, I once handcrafted one for building Mingw compilers (simple job of replacing the files in the 'include' and 'lib' directories, and 'libgcc.a' and such, with the Mingw versions. Worked like a dream - and it only took me a few minutes to achieve. Maybe it was so easy because it was a Cygwin toolchain that I emasculated so - but I doubt it.
Sorry ?
Regards,
Adriaan van Os
Adriaan van Os wrote:
- runtime library code, using POSIX calls rather than "native" Win32
calls, e.g. ReadLn using "read" rather than "ReadFile". If the POSIX emulation DLL isn't stable or 100 % compatible (I really don't know) I think there are two ways out (a) adapt the RTS to use Win32 calls (b) use Win32 calls instead of the RTS at the application level.
(c) improve the emulation library. That would fix the problem once and for all programs, instead of requiring special changes in every program (or runtime environment). To some degree (i.e., as far as necessary) we've already done this via os-hacks.h.
Frank
On 26 Oct 2004 at 11:26, Adriaan van Os wrote:
Prof. A Olowofoyeku (The African Chief) wrote:
With Mingw, you'd be advised to stick with gcc-3.2.3 until the predefines issue is sorted out.
I started out with gcc-3.2.3-20030504-1-src.tar.gz, but the tar file is apparently corrupt. I posted a message about that to mingw-users@lists.sf.net.
Ok. But you can still use the bog-standard (i.e., pristine) gcc-3.2.3.
AFAICS you can only build a Mingw GNU compiler with a cross compiler. Even the Mingw-MSYS environment is a cross compiler, since, it is simply a fork of the Cygwin project, relies on a (large) DLL to provide the POSIX emulation, and has its own "native" binaries (i.e., that rely on the DLL).
In this context, I mean with a "cross compiler" a compiler where host and target are running on different hardware and operating systems.
Yes, I am aware of that.
I do understand about the POSIX emulation DLL. I think there are two issues:
- the compiler using the POSIX emulation DLL for its operation.
However, this doesn't apply to a cross-compiler hosted on a OS with a POSIX compatible UNIX kernel, like Linux or Mac OS X (and many others). Actually, this suggests that a Win32 targeted cross-compiler running on a UNIX host is more stable than one running under POSIX emulation on Wintel itself.
That does not necessarily follow. The Cygwin and MSYS environments are pretty stable. In fact, the main purpose of MSYS is to provide an environment for building native Win32 GNU stuff.
- runtime library code, using POSIX calls rather than
"native" Win32 calls, e.g. ReadLn using "read" rather than "ReadFile". If the POSIX emulation DLL isn't stable or 100 % compatible (I really don't know) I think there are two ways out (a) adapt the RTS to use Win32 calls (b) use Win32 calls instead of the RTS at the application level.
I am not sure what this is all about. The runtime library code generated by your cross compiler will be the same as that produced by any other Mingw-targetted cross compiler (including MSYS). The Mingw libraries that are linked into the Mingw compilers and RTS are built using native Win32 calls.
I was simply making the point that there is no "native" Mingw toolchain upon which GNU tools can be built, and that you always require a "cross compiler" (widely defined) to build native Win32 versions of GNU tools.
So whether a cross-compiler is reliable or not depends on which cross compiler. Some (e.g., MSYS) are reliable, and I am sure that there are some that are not.
How compatible, stable and fast is the RTS, as compared to "native" Win32 calls ?
To the extent that the RTS consists of native Win32 calls, there is no difference. Of course there is a slight (probably insignificant) overhead that wouldn't be there if you simply called the API directly (e.g., calling the ReadFile API call instead of BlockRead).
Is it reasonable to rely on native testsuite results on both the host and the target ?
AFAIK you cannot run a "native" Mingw testsuite, since the testsuite (from what I can see - I may be wrong) requires at least (ba)sh and one or two things, for which there are no native Windows versions that can hack it.
Yeah, but you could run the testsuite on a Wintel machine under MingW.
That is what I said was impossible. The testsuite depends on the existence of at least a minimal GNU toolchain (at the very least, bash/sh, tee, echo, sed, etc.) for which there are no (or no proper) native Win32 versions. Even under Windows, you will still need a POSIX environment such as Cygwin or MSYS to run the testsuite for the Mingw compiler.
Or compile the testsuite on the host machine to a "programs" directory, transfer it to the target machine and then run the executables there.
Yes, that is possible.
As far as "cross compilers" go, I once handcrafted one for building Mingw compilers (simple job of replacing the files in the 'include' and 'lib' directories, and 'libgcc.a' and such, with the Mingw versions. Worked like a dream - and it only took me a few minutes to achieve. Maybe it was so easy because it was a Cygwin toolchain that I emasculated so - but I doubt it.
Sorry ?
About what?
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
As far as "cross compilers" go, I once handcrafted one for building Mingw compilers (simple job of replacing the files in the 'include' and 'lib' directories, and 'libgcc.a' and such, with the Mingw versions. Worked like a dream - and it only took me a few minutes to achieve. Maybe it was so easy because it was a Cygwin toolchain that I emasculated so - but I doubt it.
Sorry ?
About what?
With "Sorry ?" I meant to say that I didn't quite understand what you said in this section.
Regards,
Adriaan van Os
On 27 Oct 2004 at 0:04, Adriaan van Os wrote:
Prof A Olowofoyeku (The African Chief) wrote:
As far as "cross compilers" go, I once handcrafted one for building Mingw compilers (simple job of replacing the files in the 'include' and 'lib' directories, and 'libgcc.a' and such, with the Mingw versions. Worked like a dream - and it only took me a few minutes to achieve. Maybe it was so easy because it was a Cygwin toolchain that I emasculated so - but I doubt it.
Sorry ?
About what?
With "Sorry ?" I meant to say that I didn't quite understand what you said in this section.
Let me say it in another way - "in the bad old days before the release of MSYS, and when I tired of trying to use Cygwin to compile a Mingw compiler, and I had no clue as to what the instructions on making a Linux cross-compiler meant, I hand-crafted a Mingw-targetted but Cygwin hosted "cross compiler". I then proceeded to explain how I did this hand-crafting, which only took a few minutes to do, but worked like a dream. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
Let me say it in another way - "in the bad old days before the release of MSYS, and when I tired of trying to use Cygwin to compile a Mingw compiler, and I had no clue as to what the instructions on making a Linux cross-compiler meant, I hand-crafted a Mingw-targetted but Cygwin hosted "cross compiler". I then proceeded to explain how I did this hand-crafting, which only took a few minutes to do, but worked like a dream.
Ah, I see.
Anyway, Mingw/MSYS looks like the project that exactly fits our needs today - and the website http://www.mingw.org/ even has GPC compiler sources and binaries.
Frank Heckenbach wrote:
(c) improve the emulation library. That would fix the problem once and for all programs, instead of requiring special changes in every program (or runtime environment). To some degree (i.e., as far as necessary) we've already done this via os-hacks.h.
Yes, I found the os-hacks.h file and put it in the gcc/p/rts folder before configure and make. However, this seems to have been the wrong thing, because I read:
BUILDING A GPC COMPILER FOR CYGWIN
Cygwin has a fully functional self-hosting toolchain. The Cygwin environment implements a functional POSIX layer under Windows. Building GPC for Cygwin should (if you have the full Cygwin environment and toolchain) be as straightforward as building it under Linux.
However, in order to get a full GPC runtime library, you also need to download os-hacks.h and copy it to your Cygwin installation's "include" directory (typically /cygnus/usr/include/) before attempting to "configure" and "build" GPC.
Does this apply to Mingw also ?
Regards,
Adriaan van Os
On 27 Oct 2004 at 11:44, Adriaan van Os wrote:
Prof A Olowofoyeku (The African Chief) wrote:
Let me say it in another way - "in the bad old days before the release of MSYS, and when I tired of trying to use Cygwin to compile a Mingw compiler, and I had no clue as to what the instructions on making a Linux cross-compiler meant, I hand-crafted a Mingw-targetted but Cygwin hosted "cross compiler". I then proceeded to explain how I did this hand-crafting, which only took a few minutes to do, but worked like a dream.
Ah, I see.
Anyway, Mingw/MSYS looks like the project that exactly fits our needs today - and the website http://www.mingw.org/
Indeed.
even has GPC compiler sources and binaries.
Which I put there ;-) Just haven't bothered to update the ones on the Mingw web site, since it was easier to put the updates on the GPC web site. Now that the GPC web site is down ....
Frank Heckenbach wrote:
(c) improve the emulation library. That would fix the problem once and for all programs, instead of requiring special changes in every program (or runtime environment). To some degree (i.e., as far as necessary) we've already done this via os-hacks.h.
Yes, I found the os-hacks.h file and put it in the gcc/p/rts folder before configure and make. However, this seems to have been the wrong thing,
Yep.
because I read:
BUILDING A GPC COMPILER FOR CYGWIN
Cygwin has a fully functional self-hosting toolchain. The Cygwin environment implements a functional POSIX layer under Windows. Building GPC for Cygwin should (if you have the full Cygwin environment and toolchain) be as straightforward as building it under Linux.
However, in order to get a full GPC runtime library, you also need to download os-hacks.h and copy it to your Cygwin installation's "include" directory (typically /cygnus/usr/include/) before attempting to "configure" and "build" GPC.
Does this apply to Mingw also ?
Yes. os-hacks.h should be in the Mingw "include" directory.
BTW: there are more recent versions of the Windows os-hacks.h than the one on the Mingw web site.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.greatchief.plus.com/
On 27 Oct 2004 at 16:58, Adriaan van Os wrote:
Prof. A Olowofoyeku (The African Chief) wrote:
BTW: there are more recent versions of the Windows os-hacks.h than the one on the Mingw web site.
Can you please send it to me or point me to a place on the web where I can get it ?
Actually, 'diff' only shows one minor difference between the one on the Mingw web site and my version (to cover MSYS) - so what you have is fine (unless you want to build GPC for MSYS - which I don't recommend). Anyway, here is the diff output:
*************** *** 556,562 ****
/******************* cygwin stuff *****************/
! #if defined(__CYGWIN32__) || defined(__MSYS__)
#define realpath(path,resolved_path) \ (getenv ("CYGWIN_USE_WIN32_PATHS") \ --- 556,562 ----
/******************* cygwin stuff *****************/
! #ifdef __CYGWIN32__
#define realpath(path,resolved_path) \ (getenv ("CYGWIN_USE_WIN32_PATHS") \
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Does gpc support the COFF debug format ?
[G4:~/testgpcadriaan] adriaan% i386-mingw32msvc-gcc hello.c -o hello.exe -gcoff [G4:~/testgpcadriaan] adriaan% i386-mingw32msvc-gpc hello.pas -o hello.exe -gcoff /var/tmp//ccESsNAv.s: Assembler messages: /var/tmp//ccESsNAv.s:275: Fatal error: C_EFCN symbol out of scope
I noticed that the default for MinGW is stabs, but the advantage of COFF is that it can be read by WinDbg.
Regards,
Adriaan van Os
Adriaan van Os a écrit:
Does gpc support the COFF debug format ?
[G4:~/testgpcadriaan] adriaan% i386-mingw32msvc-gcc hello.c -o hello.exe -gcoff [G4:~/testgpcadriaan] adriaan% i386-mingw32msvc-gpc hello.pas -o hello.exe -gcoff /var/tmp//ccESsNAv.s: Assembler messages: /var/tmp//ccESsNAv.s:275: Fatal error: C_EFCN symbol out of scope
I noticed that the default for MinGW is stabs, but the advantage of COFF is that it can be read by WinDbg.
COFF originally was the default debug format for DJGPP. I had seen similar error messages at a time, after a change of gcc version. I have changed since then to stabs because it gives better debugging information, and default in DJGPP is now dwarf-2, which I have not followed, due to the need to include pascal patches for gdb indicated by waldeck in his web page (I use rhide, which includes its own (unpatched) gdb, and never tried to compile it). Keeping alive old tools is frequently a problem.
Maurice
Adriaan van Os wrote:
To my surprise and joy, I managed to build a Mac OS X hosted cross compiler targeting Windows (MingW).
The cross compiler swallows hello.pas and the resulting binary actually does say "Hello, World" at the other side of the fence. However, the question arises how reliable the cross-compiler is, as the testsuite says "if this is a cross-compiler, you can't run the test suite easily". Is it reasonable to rely on native testsuite results on both the host and the target ?
I would expect the cross-compiler to be reasonbly reliable. First, if "native" MingW compiler works correcty the remaining problems come from non-portablity of gcc/gpc code and things like mixing host and target characteristics. Gcc is frequently used as a cross-compiler, so I would expect only few problems in the backend. I know of two things which are not "right" in the gpc front end, but both should be harmless for you (ppc/Mac OS X is similar enough to i386/MingW :).
Still, if you have Windows machine handy (and enough disk space) you can run the compilation on Mac OS X and then run the resulting executables on Windows. Some time ago I modified the test script to use wine (or dosemu) to run the executables so I could test cross-compilers on i386/Linux. I had to skip tests which used custom "compile/run" script, but it was easy to handle the rest. On Mac OS X you could just copy the MingW executables to some safe place and later run them on Windows. There is a little work since you want to check for failed compilation on host. Also on target you still need the test script to set up input and check for correct output.
My change to 'test_run' was basically to call a hook (shell function) to run exectables (intead of invoking them directly). Maybe we should include such change in reased version? By default the testsuite would run the same as now, but (say) setting environment variable we could change the behaviour.
Waldek Hebisch wrote:
Still, if you have Windows machine handy (and enough disk space) you can run the compilation on Mac OS X and then run the resulting executables on Windows. Some time ago I modified the test script to use wine (or dosemu) to run the executables so I could test cross-compilers on i386/Linux. I had to skip tests which used custom "compile/run" script, but it was easy to handle the rest. On Mac OS X you could just copy the MingW executables to some safe place and later run them on Windows. There is a little work since you want to check for failed compilation on host. Also on target you still need the test script to set up input and check for correct output.
My change to 'test_run' was basically to call a hook (shell function) to run exectables (intead of invoking them directly). Maybe we should include such change in reased version? By default the testsuite would run the same as now, but (say) setting environment variable we could change the behaviour.
I think so. Of course, it should handle all tests (or say unsupported if it's really not easily possible for a few) -- e.g., call that hook from the few special compile/run scripts where necessary.
Given the number of tests, a few thoughts about efficiency might be in order, though.
Running each test over ssh (I assume that's the general case, since Wine/Dosemu, of course, works only in special cases -- same hardware, OS emulator available) might take some time. Depending on the CPU speed and authentication method, each ssh login may take a few seconds, and that for several thousands of tests. But then, several hours running time may just be acceptable ...
Running all the tests over a single ssh login might be faster, but probably more difficult to write (interacting with a remote shell, transfer of binaries).
The third way, compiling everything first, transferring the binaries and running them remotely, is also more difficult to arrange. Also it raises questions of executable size (unfortunately -- though strip and tar.bz2 seem to bring them down to ~50 KB per binary, about 200 MB in total ...) Also, tests that require a program to run remotely before the actual compilation (such as fjf77) would require several steps here and there. Fortunately, there are very few of them ...
Frank
-
Adriaan van Os -
Frank Heckenbach -
Maurice Lombardi -
Prof A Olowofoyeku (The African Chief) -
Prof. A Olowofoyeku (The African Chief)
-
Waldek Hebisch