[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a
--- Comment #15 from sayle at gcc dot gnu dot org 2008-02-01 17:42 --- Subject: Bug 33781 Author: sayle Date: Fri Feb 1 17:41:48 2008 New Revision: 132047 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132047 Log: PR bootstrap/33781 * configure.ac (--enable-fixed-point): Disable unless explicitly requested on IRIX. * configure: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2008-01-31 10:38 --- (In reply to comment #8) I'll respond to Jakub's latest comments before trying DJ's more recent patch. Running getconf ARG_MAX on my IRIX box, returns 20480, which is 20K. I believe this is the default, out of the box setting for my machine which is running IRIX 6.5.19m. I've had the same problem, and it indeed goes away if you set your ARG_MAX to something higher (I have 262144, which is the maximum possible value). It is even mentioned in the target specific installation notes, though it says there it is only required for Java. Maybe the target notes should be updated? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Keywords||documentation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a
--- Comment #8 from roger at eyesopen dot com 2007-11-02 16:41 --- Created an attachment (id=14471) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14471action=view) Default libgcc.a objects on mips-sgi-irix6.5 I'll respond to Jakub's latest comments before trying DJ's more recent patch. Running getconf ARG_MAX on my IRIX box, returns 20480, which is 20K. I believe this is the default, out of the box setting for my machine which is running IRIX 6.5.19m. Using cut'n'paste from the failing make output, I measure the current $$objects to be 25949 bytes. I've attached the attempted value of $objects to this e-mail. I'll give DJ's patch a spin... I apologise that this box isn't that speedy. Roger -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a
--- Comment #11 from jakub at gcc dot gnu dot org 2007-11-02 18:40 --- No wonder I haven't seen so big $$objects in my x86_64-linux build (not that 20KB would be a big deal there). I guess we shouldn't then split libgcc-objects into so many small objects, but instead just use objects=$(filter-out _fract% _satfract%, $(objects)) and then run AR_FOR_TARGET again also for $(filter _fract%, $(objects)) and $(filter _satfract%, $(objects)) if either is not empty. That could cure libgcc.a, but libgcc-s-objects is probably big as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a
--- Comment #9 from roger at eyesopen dot com 2007-11-02 17:12 --- Doh! DJ's patch gets us a little further, but it things are still broken. However, it's an excellent debugging tool which shows that its the invocation with libgcc-objects-15 that's broken. Applying the same trick as above shows that $libgcc-objects-15 alone is 19962 bytes, which combined with the ar etc.. at the beginning of the command line exceeds the limits. So it's the fixed-conv-funcs that are to blame. Perhaps gen-fixed.sh has gone insane with the large number of integer-like machine modes on MIPS. The correct fix might actually be in the optabs handling of the middle-end, so we don't need quite so many conversion functions in MIPS' libgcc.a. Or perhaps mips.md need improved support (patterns) for this functionality. I've no idea what _satfractunsUTIUHA is, it's a recent addition and I've not been following gcc-patches lately. Splitting _fract* from _sat* with a patch similar to DJ's should work. I hope this is enlightening. Is there a --disable-option to avoid building fixed point conversion support? Looks like our command line usage is O(n^2) in the number of backend integer machine modes? Thanks again for everyone's help on this. I'll owe you beers at the next GCC summit. Roger -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a
--- Comment #10 from dj at redhat dot com 2007-11-02 17:41 --- Subject: Re: [4.3 Regression] Arg list too long building libgcc.a You could try splitting that one in two with gmake's $(filter ) and $(filter-out ) functions. The only trick would be finding a simple pattern that matches half the objects. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a
--- Comment #12 from dj at redhat dot com 2007-11-02 18:56 --- Created an attachment (id=14472) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14472action=view) test patch 3 This one just breaks up #15 into three chunks, with everything else in a single chunk. -- dj at redhat dot com changed: What|Removed |Added Attachment #14457|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a
--- Comment #13 from dj at redhat dot com 2007-11-02 18:58 --- Created an attachment (id=14473) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14473action=view) sclsh - short command line shell Here's a short perl script that acts as a short command line shell - it complains about any command line longer than 3k bytes. Use make SHELL=sclsh Edit as needed. It also tells you how long each command line is, although it doesn't work around command lines that exceed system limits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a
--- Comment #3 from dj at redhat dot com 2007-11-01 16:03 --- Created an attachment (id=14453) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14453action=view) test patch Could you give this a try on IRIX? It's just an officialized copy of Jakub's suggestion. My only concern is using the c flag to ar more than once - it doesn't purge the archive under Linux, but who knows what other OSs will do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a
--- Comment #4 from roger at eyesopen dot com 2007-11-01 17:15 ---
Thanks to both Jakub and DJ for their help. I just tried out the suggested
patch on my IRIX box, and was surprised that it didn't resolve the error.
My apologies that my initial analysis might have been wrong (or incomplete),
but it looks like the error occurs earlier on the same command line.
Not only does,
objects=$(objects) ; $(AR_CREATE_FOR_TARGET) $@ $$objects
Infact, stripping the command back to just
objects=$(objects)
is enough to trigger the error. Hoping that this was perhaps a limitation
of IRIX's /bin/sh, I've tried again with SHELL=/usr/local/bin/bash but alas
I get the same error.
make: execvp: /usr/local/bin/bash: Arg list too long
So it's not a bound on argc or the number of entries in argv[] that's the
problem, but a hard limitation on command line length.
So it looks like we can't even assign $objects yet alone use it, either
directly or looping over it to use xargs. Perhaps we could do something
with find. Just a wild guess here as I don't understand build machinery
but something like:
find . -name '*.o' -exec ar rc libgcc.a {} \;
And then test afterwards
if test ! -f libgcc.a ; then
{the eh_dummy.o stuff to avoid empty libgcc.a} ;
fi
I'm not sure why I'm seeing this. There mustn't be many IRIX testers for
mainline and either MIPS is building more objects than other platforms (for
saturating and fixed point math) or most OSes are less restricted than
IRIX.
Many thanks again for peoples help. Is find portable, or is there a
better way to achieve the same thing without ever placing all of the filenames
on a single command line?
Sorry for any inconvenience.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a
--- Comment #5 from dj at redhat dot com 2007-11-01 20:02 --- Created an attachment (id=14457) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14457action=view) test patch 2 Here's another try. We collect the libgcc.a objects in multiple variables (18 of them) so that we can invoke $(AR) multiple times. Hopefully, this will result in individual command lines that meet IRIX's limits. What is your systune'd command line limit, anyway? If needed, we can apply this technique to other libraries too. -- dj at redhat dot com changed: What|Removed |Added Attachment #14453|0 |1 is obsolete|| AssignedTo|unassigned at gcc dot gnu |dj at redhat dot com |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a
--- Comment #6 from jakub at gcc dot gnu dot org 2007-11-01 22:26 --- BTW, $$objects is just slightly over 2KB, so if Irix really limits command line lengths to 2KB, I'm very much surprised more things don't break there every now and then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a
--- Comment #7 from jakub at gcc dot gnu dot org 2007-11-01 22:35 --- Can you run getconf ARG_MAX ? If you configure with --disable-decimal-float does it build? What sizes have the $(dfp-objects), $(decbits-objects), $(d32pbit-o), $(d64pbit-o), $(d128pbit-o) vars in the build that fails? I doubt we need 18 subvars as in test patch 2, otherwise I don't see how libgcc.a could ever link on Irix in gcc 4.2 or before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a
--- Comment #1 from jakub at gcc dot gnu dot org 2007-10-30 14:01 --- Untested patch that could help: --- libgcc/Makefile.in 2007-09-28 08:29:29.0 +0200 +++ libgcc/Makefile.in 2007-10-30 14:55:38.0 +0100 @@ -1,6 +1,6 @@ # Makefile.in -# Copyright (C) 2005, 2006 Free Software Foundation +# Copyright (C) 2005, 2006, 2007 Free Software Foundation # # This file is part of GCC. # @@ -694,7 +694,7 @@ libgcc.a libgcov.a libunwind.a libgcc_eh -o eh_dummy$(objext); \ objects=eh_dummy$(objext);\ fi; \ - $(AR_CREATE_FOR_TARGET) $@ $$objects + ls $$objects | xargs $(AR_CREATE_FOR_TARGET) $@ $(RANLIB) $@ Or is the problem not in the size of the arguments on the exec side, but just buggy ar that imposes further limits on the length of the command line? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a
--- Comment #2 from jakub at gcc dot gnu dot org 2007-10-30 14:03 --- Actually, that would need to be for f in $$objects; do echo $$f; done | xargs $(AR_FOR_TARGET) $@ Sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
