This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Libjava craziness
On May 18, 2001, Mark Mitchell <mark@codesourcery.com> wrote:
>>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
Alexandre> On May 17, 2001, Mark Mitchell <mark@codesourcery.com>
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
else
i=0
- 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
do
i=`expr $i + 1`
testring=$testring$testring
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me