Mail Archives: djgpp-workers/2001/06/24/05:36:37
> 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
- Raw text -