X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
Subject: Re: [ANNOUNCE] DJGPP port of gcc-6.1.0
To: djgpp AT delorie DOT com
References: <201604281739 DOT u3SHdF9o009018 AT delorie DOT com>
 <572B61D5 DOT 2040400 AT gmx DOT de> <16909c8a-d835-21ab-67fb-9dcd397b630b AT iki DOT fi>
 <572F7363 DOT 10503 AT gmx DOT de> <ngq5iu$9e7$1 AT usenet DOT news DOT interia DOT pl>
 <2e24511c-70d0-42fd-e7bb-15cb7c265c25 AT iki DOT fi>
 <ngqlq5$bc0$1 AT usenet DOT news DOT interia DOT pl>
 <33c66609-1021-0a49-be8c-42428cdaca41 AT iki DOT fi>
 <ngtn14$k4n$1 AT usenet DOT news DOT interia DOT pl>
 <9039c19a-0630-4789-a282-71b83d95d665 AT googlegroups DOT com>
 <8d49fc45-0a00-4b22-af5b-6d841492c1f3 AT googlegroups DOT com>
From: "Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
Message-ID: <87a1b41a-c7d6-ca40-2325-98bf893ae691@iki.fi>
Date: Sun, 15 May 2016 00:42:37 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <8d49fc45-0a00-4b22-af5b-6d841492c1f3@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On 05/14/2016 08:59 PM, Juan Manuel Guerrero (juan DOT guerrero AT gmx DOT de) [via djgpp AT delorie DOT com] wrote:
> Am Samstag, 14. Mai 2016 13:22:51 UTC+2 schrieb RayeR:
>> Hm, it remembers me problems of compiling FFMPEG package. In that case I needed to increase transferbuffer in stub, not the stack. So I made a batch to necessary DJGPP files:
>> stubedit MAKE.EXE bufsize=32K
>> stubedit AR.EXE bufsize=32K
>> stubedit RM.EXE bufsize=32K
>> that I need to run after every update of binutils and other packages to keep it fixed. I think it should be mentioned in main djgpp readme to describe some symptoms and what to set with stubedit to fix it.
> Is ar.exe the only binutils program that needs a larger transfer buffer?
It is less critical in Windows 10 rather than Windows Vista (I do not remember about XP, but I 
suspect it was the same as for Windows Vista):
- in Windows 10 VM I'm getting largest executable DOS program size 631200 bytes as reported by 'mem'
- in Windows Vista - only 570400

src/dos/dosexec.c allocates extra buffer when command line arguments do not fit in transfer buffer.
That however leaves less DOS memory available for child processes. For GCC build the number of 
nested processes is large enough to have danger of running out of DOS memory.

ar.exe or rm.exe is perhaps not critical any more (was before allocating extra area for parameters 
were implemented) unless they are called very deeply in build process with huge number of parameters.

make.exe is more critical: I have had build process run out of DOS memory  while bootstrapping GCC 
unless make transfer buffer size was increased to 24KB.

Andris