Hiya Frank
- I get this error:
parse.c:368: conflicting types for `bool' /usr/lib/gcc-lib/i686-pc-msys/2.95.3-1/include/stdbool.h:11: previous declaration of `bool'
Probably also the bison version.
- I have to pass "--cstrings-as-strings" and "--pointer-arithmetic" in
RTSFLAGS to build string.pas - else it complains about things not being arrays, etc.
That's strange since these are there as compiler options (line 178). Which errors do you get otherwise? Unless they're before that line (i.e., in the interface which would be strange), compiler options seem to be broken. Can you reduce it to a small failing test case?
- This code (in rts.c) causes problems: #ifdef HAVE_TM_GMTOFF if (TimeZone) *TimeZone = t->tm_gmtoff; #else if (TimeZone) *TimeZone = -timezone; #endif
It doesn't like the "-timezone" so I changed it to 0. That compiles for now, but I am not sure what problems this will cause in the future.
On 19 Aug I wrote:
: Waldek Hebisch wrote: : : > Right. I see were the problem is: Cygwin defines `timezone' as a function. : > Configure uses the following test: : > : > #include "confdefs.h" : > : > #define _GNU_SOURCE : > #define _LARGEFILE64_SOURCE : > #define _FILE_OFFSET_BITS 64 : > #include <time.h> : > volatile long int tmp; : > int main() { : > tmp = timezone; : > ; return 0; } : > : > Appearently, the test succeeds (only gives warning) if `timezone' is : > a function (maybe use '-timezone' in integer tests)?. : : Have you tried it and does it work? If so, I'll change it.
Since the thread died after my mail, I haven't changed anything. You might want to try that now.
That's the last occurrence of `timezone' in rts/configure. Also, in the test with the first occurrence of `timezone' you might have to insert: #include <time.h>
Then remove everything in <build>/gcc/p/rts and rebuild. `HAVE_TIMEZONE' and `TIMEZONE_DECLARED' should be unset.
If that works, I'll have to do the respective changes in configure.in.
Frank
On 14 Oct 2003 at 7:20, Frank Heckenbach wrote:
- I get this error:
parse.c:368: conflicting types for `bool' /usr/lib/gcc-lib/i686-pc-msys/2.95.3-1/include/stdbool.h:11: previous declaration of `bool'
Probably also the bison version.
It was ... I have had some success with the MSYS build of GPC after sorting out bison issues. I am yet to run the testsuite - but my own little suite of test programs are working okay at the moment ...
- I have to pass "--cstrings-as-strings" and "--pointer-arithmetic"
in RTSFLAGS to build string.pas - else it complains about things not being arrays, etc.
That's strange since these are there as compiler options (line 178). Which errors do you get otherwise? Unless they're before that line (i.e., in the interface which would be strange), compiler options seem to be broken. Can you reduce it to a small failing test case?
The whole thing was broken (by the bison problems). I have just rebuilt GPC (using "make bootstrap") and that problem seems to have disappeared too.
[...]
: Waldek Hebisch wrote: : : > Right. I see were the problem is: Cygwin defines `timezone' as a function. : > Configure uses the following test: : > : > #include "confdefs.h" : > : > #define _GNU_SOURCE : > #define _LARGEFILE64_SOURCE : > #define _FILE_OFFSET_BITS 64 : > #include <time.h> : > volatile long int tmp; : > int main() { : > tmp = timezone; : > ; return 0; } : > : > Appearently, the test succeeds (only gives warning) if `timezone' is : > a function (maybe use '-timezone' in integer tests)?. : : Have you tried it and does it work? If so, I'll change it.
Since the thread died after my mail, I haven't changed anything. You might want to try that now.
That's the last occurrence of `timezone' in rts/configure. Also, in the test with the first occurrence of `timezone' you might have to insert: #include <time.h>
Then remove everything in <build>/gcc/p/rts and rebuild. `HAVE_TIMEZONE' and `TIMEZONE_DECLARED' should be unset.
If that works, I'll have to do the respective changes in configure.in.
This is what I did - and it seems to have solved the timezone problem:
#line 2165 "configure" #include "confdefs.h" #include <time.h> #undef timezone extern long int timezone ; volatile long int tmp; int main() { tmp = -timezone; ; return 0; }
The result is that I now have a functional gpc-20030830 for MSYS, based on gcc-3.2.3. I will run the testsuite in due course and see what happens.
But I have come across a little snag. MSYS is a minimalist POSIX environment for Windows. So, it uses front slashes and all that. My little problem arose with FileExists(). Assume a filename 'foo.cfg'. Expand it into a fully qualified pathname with GPC and it becomes '/d/bar/foo.cfg' (where "/d" is the drive d:). It seems that FileExists cannot cope with this expanded filename, or with the alternative after it has been converted by the Slash2OSDir... stuff (i.e., '\d\bar\foo.cfg'). The file is said not to exist. I wrote a little hack to see how I could solve this:
function MSYSPath2DosPath (Const s : String): String; Var i : Cardinal; begin Result := s; {$ifdef __MSYS__} if (Result [1] in ['/', '']) and (Upcase (Result[2]) in ['A'..'Z']) and (Pos (':', Result) = 0) then begin delete (Result, 1, 1); insert (':', Result, 2); end; {$endif} end;
At the return of this routine, '\d\bar\foo.cfg' or '/d/bar/foo.cfg' becomes 'd:\bar\foo.cfg' or 'd:/bar/foo.cfg'. MSYS and FileExists seem to both be happy with either of these results. I am sure that this problem will exist elsewhere in the RTS and not just with FileExists. The question is how we can solve it in the RTS (perhaps in the Slash2OSDir stuff).
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku (The African Chief) wrote:
But I have come across a little snag. MSYS is a minimalist POSIX environment for Windows. So, it uses front slashes and all that. My little problem arose with FileExists(). Assume a filename 'foo.cfg'. Expand it into a fully qualified pathname with GPC and it becomes '/d/bar/foo.cfg' (where "/d" is the drive d:).
Does realpath (C function) return that, or did we anything special about it (I don't remember all this)?
It seems that FileExists cannot cope with this expanded filename, or with the alternative after it has been converted by the Slash2OSDir... stuff (i.e., '\d\bar\foo.cfg'). The file is said not to exist. I wrote a little hack to see how I could solve this:
function MSYSPath2DosPath (Const s : String): String; Var i : Cardinal; begin Result := s; {$ifdef __MSYS__} if (Result [1] in ['/', '']) and (Upcase (Result[2]) in ['A'..'Z']) and (Pos (':', Result) = 0) then begin delete (Result, 1, 1); insert (':', Result, 2); end; {$endif} end;
At the return of this routine, '\d\bar\foo.cfg' or '/d/bar/foo.cfg' becomes 'd:\bar\foo.cfg' or 'd:/bar/foo.cfg'. MSYS and FileExists seem to both be happy with either of these results. I am sure that this problem will exist elsewhere in the RTS and not just with FileExists. The question is how we can solve it in the RTS (perhaps in the Slash2OSDir stuff).
Yes, I think so. Is this `/d/foo/...' form supposed to "exist" at all?
And if so, can this be assumed to always mean `d:/foo'? -- At least under old Dos, it could also mean directory `/d/foo' on the current drive. Or are such directories just not supposed to exist, and bad luck otherwise (or they should write `f:/d/foo' then, including the drive)?
If that's not the case, we might have to check for the existence of such a `/d' directory which would be extra programming effort, and might be expensive at runtime to do for every Slash2OSDirSeparator call (which is expected to be a cheap operation, WRT I/O).
If the `/d/foo' form is not supposed to occur in the first place, then I think we should rather fix realpath (and possibly other routines that produce such a form).
Frank
On 15 Oct 2003 at 5:44, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
But I have come across a little snag. MSYS is a minimalist POSIX environment for Windows. So, it uses front slashes and all that. My little problem arose with FileExists(). Assume a filename 'foo.cfg'. Expand it into a fully qualified pathname with GPC and it becomes '/d/bar/foo.cfg' (where "/d" is the drive d:).
Does realpath (C function) return that, or did we anything special about it (I don't remember all this)?
As indicated in my last post, the problem is solved now by the small patch to filename.pas.
It seems that FileExists cannot cope with this expanded filename, or with the alternative after it has been converted by the Slash2OSDir... stuff (i.e., '\d\bar\foo.cfg'). The file is said not to exist. I wrote a little hack to see how I could solve this:
function MSYSPath2DosPath (Const s : String): String; Var i : Cardinal; begin Result := s; {$ifdef __MSYS__} if (Result [1] in ['/', '']) and (Upcase (Result[2]) in ['A'..'Z']) and (Pos (':', Result) = 0) then begin delete (Result, 1, 1); insert (':', Result, 2); end; {$endif} end;
At the return of this routine, '\d\bar\foo.cfg' or '/d/bar/foo.cfg' becomes 'd:\bar\foo.cfg' or 'd:/bar/foo.cfg'. MSYS and FileExists seem to both be happy with either of these results. I am sure that this problem will exist elsewhere in the RTS and not just with FileExists. The question is how we can solve it in the RTS (perhaps in the Slash2OSDir stuff).
Yes, I think so. Is this `/d/foo/...' form supposed to "exist" at all?
Yes. "/d" is what "d:" is mounted as. This is done automatically by the MSYS runtime. This is an excerpt from the output of "mount".
D:\msys\1.0\bin on /usr/bin type user (binmode,cygexec,noumount) D:\msys\1.0\bin on /bin type user (binmode,cygexec,noumount) D:\msys\1.0 on / type user (binmode,noumount) D:\msys\1.0 on /usr type user (binmode,noumount) d:\mingw on /mingw type user (binmode) d:\src on /src type user (binmode) a: on /a type user (binmode,noumount) c: on /c type user (binmode,noumount) d: on /d type user (binmode,noumount) [...]
So, all is well now. I have run the testsuite and all the tests are passed (with a few skipped ones). I believe that the MSYS version of gpc-20030830 is as solid (or not) as the Mingw and Cygwin versions. An excerpt from the test log:
rm -f *.dat *.o *.s *.i *.gpi *.gpd *.gpc core a.out stderr.out *.exe testmake.tmp dummy.c dummy.pas dummy.out diff_cr*.tmp fixcr fixcr.exe rm -f todo/a.out todo/*.exe todo/*.o todo/*.s todo/*.i todo/*.gpi todo/*.gpd todo/core { gpc --version | head -1; gpc --print-search-dirs | grep install | head -1; hostname || echo "unknown host"; date "+%Y-%m-%d %H:%M:%S"; } | \ sed -e 's,^,Testing ,;N;s,\n.*gcc-lib[/], (,;s,[/].*,),;N;s,\n, (,;s,$,),;N;s/\n/, /' Testing gpc 20030830, based on gcc-3.2.3 (mingw special 20030504-1) (i686-pc-msys) (my-pc), 2003-10-15 17:37:58 echo "gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused " gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused PC="gpc" PFLAGS="--autobuild -g -O3 -W -Wall -Wundef -Wpointer-arith - Wno-unused " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "*.pas" | tee test_log GPC-TEST-BEGIN ========================== [...] TEST writeg.pas: OK TEST writereal.pas: OK TEST y2k.pas: OK ========================== GPC-TEST-END
As you can see, it didn't report the number of passed, skipped, or failed tests - but there is no failed test. I think we can add MSYS to the list of supported platforms now. I will release binaries in due course.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku (The African Chief) wrote:
As you can see, it didn't report the number of passed, skipped, or failed tests - but there is no failed test. I think we can add MSYS to the list of supported platforms now. I will release binaries in due course.
I'll add it in the next release. Do you have a general URL (such as http://www.mingw.org)?
Frank
On 16 Oct 2003 at 3:28, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
As you can see, it didn't report the number of passed, skipped, or failed tests - but there is no failed test. I think we can add MSYS to the list of supported platforms now. I will release binaries in due course.
I'll add it in the next release. Do you have a general URL (such as http://www.mingw.org)?
http://www.mingw.org/msys.shtml
But it is the same site as Mingw.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
-
Frank Heckenbach -
Prof A Olowofoyeku (The African Chief)