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/