Ken Linder wrote:
Ok, I added the following code into the hdr.h file:
... #include "varargs.h" ... extern void _p_write PROTO((FDR, int, int, __va_ellipsis)); extern void _p_read PROTO((FDR, int, int, __va_ellipsis)); extern int _p_string PROTO((int, __va_ellipsis)); extern void _p_writestr PROTO((int, char *, int, __va_ellipsis)); extern void _p_readstr PROTO(char *, int, int, int, __va_ellipsis));
Well, Peter, I think the above varargs will work fine with Intel Linux but will probably do wierd things on other platforms. Hey, its my first shot at it! :-)
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?)
The above fixed my immediate problems... but now when trying to compile pascal code, I get problems linking to _p_strlen, _p_gpc_locase, and _p_gpc_upcase. ARRGGHHH. I can't seem to find where these fcns are defined in the RTS.
(* 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).
Also, do I need to fix up the Makefile? I change hdr.h but when I do a MAKE, nothing realy happens... :-#
Yes, the Makefiles are quite broken in this regard. :-( Even worse if you should make substantial changes (esp. changing the size of some RTS data structure) in rts/types.h -- then you need to recompile some parts of the compiler, or you might get very strange behaviour, i.e. you better do a complete rebuild then...
Frank
-- Frank Heckenbach, frank@fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan
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 %<
On Mon, Jan 18, 1999 at 12:21:50AM -0800, Ken Linder wrote:
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 don't know. However, libc.info file mentions that varargs.h is used for old-style pre-ISO-C variadic functions. I think it would be a safer bet to use stdarg.h instead.
Just my $0.02... -- Marius Gedminas "A Hacker is any person who derives E-mail: mgedmin@pub.osf.lt joy from discovering ways to WWW: http://www-public.osf.lt/~mgedmin/ circumvent limitations." rab'86
-
Frank Heckenbach -
Ken Linder -
Marius Gedminas