delorie.com/archives/browse.cgi | search |
X-Authentication-Warning: | delorie.com: mail set sender to djgpp-workers-bounces using -f |
From: | Andris Pavenis <pavenis AT latnet DOT lv> |
To: | djgpp-workers AT delorie DOT com |
Subject: | Problems with long command lines in DJGPP |
Date: | Mon, 24 Jan 2005 18:04:18 +0200 |
User-Agent: | KMail/1.7.91 |
MIME-Version: | 1.0 |
Message-Id: | <200501241804.18985.pavenis@latnet.lv> |
X-Virus-Scanned: | by amavisd-new at fgi.fi |
Reply-To: | djgpp-workers AT delorie DOT com |
In last time I have several times met problems with too long command lines running DJGPP programs. I some cases that can be workarounded by increasing transfer buffer size (for example setting it to 32K by stubedit). Some examples: Building current development versions of gcc-4.0.0 if Ada support is enabled. In that case bootstrap runs up to place where transfer buffer size is too small. I can increase it to 32K for xgcc.exe and collect2.exe and rerun bootstrap, so it can finish Building libgdb/librhgdb.a in RHIDE causes similar problems if rhide directory is deep enough. I don't like idea about increasing the default transfer buffer size. Perhaps it would be better in dosexec.c to write command line arguments to temporary file and after that use @filename instead when transfer buffer is to small. At this moment I don't have any patch, but anyway such update should not break already working code (command line is not too long) as in that case nothing changes Of course if command line already contains @foo construction and is too long at the same time, then we have a trouble. Andris
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |