From: "Tim Van Holder" To: Subject: Re: Compile gcc 3.0 Date: Sun, 24 Jun 2001 11:23:14 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > Did someone submit some changes to the libtool maintainers to fix this > problem? I think we should do that ASAP, since DJGPP v2.04 is still > far away, so we will have to live with the problem for some time. > Meanwhile, more and more GNU projects start using this version of > libtool. That's the problem with libtool - too many versions. libtool 1.4 does not have this test, but versions from the multi-language branch (as used by the gcc and gdb/binutils trees) do. I'll submit a patch against CVS HEAD later today. > I think the only reasonable way to fix that would be for libtool to > skip this test completely for DJGPP, and use a static limit (like > 12KB) instead. That's because even if we fix glob to not blow away Will do - does this seem acceptable to you? AC_DEFUN([AC_LIBTOOL_SYS_MAX_CMD_LEN], [max_cmd_len= # find the maximum length of command line arguments +dnl On DJGPP, this test can blow up pretty badly due to problems in libc +dnl (any single argument exceeding 2000 bytes causes a buffer overrun during +dnl glob expansion). Even if that were fixed, the result of this check would +dnl be larger than it should be. So override it here. +case $host_os in + msdosdjgpp*) lt_cv_sys_max_cmd_len=12288;; # 12K is about right +esac AC_MSG_CHECKING([the maximum length of command line arguments]) AC_CACHE_VAL([lt_cv_sys_max_cmd_len], [dnl i=0