Mail Archives: djgpp-workers/2005/01/26/02:13:54
On Tuesday 25 January 2005 22:04, Eli Zaretskii wrote:
> > 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?
I met similar problems building RHIDE, when it's root directory is
deep enough and maybe somewhere else ( I don't remember)
> > > 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?
Some type casts due to comparison of signed and unsigned integers etc.
> > 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?
Well, looked in log of this night build of CVS version of gcc-4.0.0 under
Linux: libtool configuration found the max. command line length to be 48K.
So maybe 64K could be enough.
> > 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?
There is 2 or 3 places where an error happens where building gcc-4.0.0. This
approach can fix only one of them.
1) probably make.exe invoking xgcc.exe (I have increased buffer size for make,
so I didn't see that)
2) xgcc.exe invoking collect2.exe (workaround could fix that)
3) collect2.exe invoking ld.exe (workaround will not not fix it)
I tried my suggestion yesterday, but it doesn't seem so simple as I thought.
So maybe really I should return to reallocating DOS memory block used to
pass command line.
Andris
PS. maybe it is time to get rid of collect2.exe in DJGPP port of gcc. It's do
something real in case of use of option -frepo AFAIK. -frepo is unlikely
needed at all when we have weak symbol support already for long time.
- Raw text -