YES! It worked! I have successfully built the compiler! I know, this may be a minor thing for some of you out there, but for me, this is a large accomplishment!
I did a 'make LANGUAGES=pascal CFLAGS="-O2" RTSFLAGS=-Wall -j20' YEE HA!
Anyways, more explanation on the extra 'int' before the __va_ellipsis is because the definition of va_dcl in the gcc-2.8.1/include/varargs.h specifies it as: int __builtin_va_alist; __va_ellipsis
Since this don't work too well in a fcn prototype, I just coded the proto as int; __va_ellipsis. Is this portable? I think it is on Intel based hardware but otherwise no. I base this on the fact that there are many #defines for va_dcl in the va-*.h files in the gcc-2.8.1/include dir. Why can't there be something like va_dclp, generated in the varargs.h that will allow protos to be portable? Maybe there is & I just missed it. Definitely possible at this time of night! ;-)
Good night all... Ken Linder KC7RAD
At 04:33 PM 1/17/99 +0100, you wrote:
Ken Linder wrote:
Ok, I added the following code into the hdr.h file:
... #include "varargs.h" ...
%< SNIP %<
What I don't really understand is the additional `int' parameter before the ellipsis. Yes, I see that GCC wants it, but why? And is this portable? (Anyone knows for sure?)
%< SNIP %<
(* They're defined in rts/gstrings.pas. Some other people had problems finding the definitions, too -- seems they're not used to things being implemented in Pascal actually. ;-) *)
I do see the protos though. Would anyone care to shove me in the right direction to solve this?
This is a known bug caused by inline functions being compiled without optimization. So there are two obvious solutions: remove the `inline' from these functions (the next GPC version will have this done), or compile with optimization, i.e. give `CFLAGS=-O2' to the make command line (the latter is, of course, preferable, since it produces a faster compiler, anyway).
%< SNIP %<