Mail Archives: djgpp-workers/2005/01/25/15:10:10
> From: Andris Pavenis <pavenis AT latnet DOT lv>
> Date: Tue, 25 Jan 2005 11:05:26 +0200
> Cc: "Eli Zaretskii" <eliz AT gnu DOT org>
>
> > This problem can be easily fixed by changing the GCC bootstrap
> > scripts to stubedit xgcc.exe, no?
>
> Maybe. But it's not only case where this problem can occur.
Where else?
> > Alternatively, we could enable the (currently disabled) code in
> > dosexec.c that reallocates the transfer buffer if the original size is
> > not enough. See the function check_talloc there.
>
> Tried. Initially it didn't compile (-Wall -W... -Werror) with
> gcc-3.4.3.
What were the warnings/errors, and how did you fix them?
> When I got it to compile and got it really allocate a bigger buffer,
> then it still didn't work.
Most probably, some code written lately doesn't account for the
reallocation, or perhaps there's some bug (although I did test the
disabled code back when I wrote it). Perhaps some debugging is in
order.
> Also it is limited to 64K.
?? Do you mean that your command line is longer than that? If so, I
believe other systems should fail as well, as many shells are limited
to less than that. Didn't maintainers of other ports complain yet?
> 5) put @filename instead of full argument string to transfer buffer
> 6) after that we may continue as earlier, only temporary file must be
> removed when it is no more needed.
IIRC, methods that rely on temporary files have problems because in
some situations you cannot remove the temporary file before dosexec
returns. I've been there before (see system.c for a comment that
includes the string "response file").
Actually, now that I looked into system.c, it seems like you could
work around the problem by forcing Make to invoke the xgcc command via
Bash (e.g., by adding quoting or pipe/redirection characters). When
that happens, Make should invoke the `system' library function, which
will see that the shell is a Unixy shell, and use the file method
internally.
Does that work?
- Raw text -