| delorie.com/archives/browse.cgi | search |
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
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |