[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Libjava craziness

From: Alexandre Oliva
Subject: Re: Libjava craziness
Date: 18 May 2001 02:26:28 -0300
User-agent: Gnus/5.090002 (Oort Gnus v0.02) XEmacs/21.1 (Cuyahoga Valley)

On May 18, 2001, Mark Mitchell <address@hidden> wrote:

>>>>>> "Alexandre" == Alexandre Oliva <address@hidden> writes:
Alexandre> On May 17, 2001, Mark Mitchell <address@hidden>
Alexandre> wrote:

>>> The cause is the following wonderful N^2 algorithm used to
>>> produce the library:
Alexandre> Looks like something went wrong in the test that
Alexandre> detects the maximum command-line length.  Look for
Alexandre> lt_cv_sys_max_cmd_len in config.cache and for
Alexandre> max_cmd_len in libtool.  If you could find out why it
Alexandre> got a small value for you, it would be appreciated.

> Thanks for the quick reply.

> Rats.  I deleted the 7GB already.  I'm trying again -- and perversely
> hoping it will happen again.

It certainly will, if you got the same failure in max cmd line lenght
detection.  It detected a maximum command line of 37 bytes.

> Here is what I have from the log -- and it appears you guess is
> correct:

>   finding the maximum length of command line arguments... 
> ../../../libstdc++-v3/../ltconfig: Can't reopen pipe to command substitution 
> (fd 4): No child processes
>   ../../../libstdc++-v3/../ltconfig: test: !=: unary operator expected
>   37

Looks like a problem in bash.  Here's a tentative solution:

> Looking at the loop that does this check, it should have terminated
> when $i was 32.

That would have been a maximum length of 6^{32}, not 32.  Here's a
patch that fixes an incorrect use of the non-portable `==' operator
(I'm hoping this might help fixing the problem, but I really don't see
how it would), and adjusts the initial string and maximum trip count
so that we actually stop at 1 MB, as originally intended.  Mark, could
you please let me know whether it helps.  Libtoolers, ok to install?

> It seems like it would be better to do the deletions as we go, in any
> case

Agreed.  Robert [who originally implemented piecewise linking], would
you be willing to contribute this improvement over your code?  I
suppose it's just a matter of saving the name of the previous piece in
a variable, and removing it after using it to link a new piece,
instead of keeping the whole list and removing them all at the end.

Index: ltconfig
RCS file: /cvs/gcc/egcs/ltconfig,v
retrieving revision 1.19
diff -u -p -r1.19 ltconfig
--- ltconfig 2001/04/20 09:26:56 1.19
+++ ltconfig 2001/05/18 05:19:13
@@ -783,11 +783,11 @@ if test "${lt_cv_sys_max_cmd_len+set}" =
   echo $ac_n "(cached) $ac_c" 1>&6
-  testring="ABCDEF"
-  while test `$CONFIG_SHELL $0 --fallback-echo "X$testring" >/dev/null 2>&1` 
== `echo "X$testring" >/dev/null 2>&1` &&
+  testring="ABCD"
+  while test `$CONFIG_SHELL $0 --fallback-echo "X$testring" 2>/dev/null` = 
`echo "X$testring" 2>/dev/null` &&
           new_result=`expr "X$testring" : ".*" 2>&1` &&
           lt_cv_sys_max_cmd_len=$new_result &&
-          test $i != 32 # 1 MB should be enough
+          test $i != 18 # 1 MB should be enough
     i=`expr $i + 1`
Alexandre Oliva   Enjoy Guarana', see
Red Hat GCC Developer                  address@hidden,}
CS PhD student at IC-Unicamp        address@hidden,}
Free Software Evangelist    *Please* write to mailing lists, not to me

reply via email to

[Prev in Thread] Current Thread [Next in Thread]