Bug 33781 - [4.8/4.9/5 Regression] "Arg list too long" building libgcc.a
[4.8/4.9/5 Regression] "Arg list too long" building libgcc.a
Status: ASSIGNED
Product: gcc
Classification: Unclassified
Component: bootstrap
4.3.0
: P5 minor
: 4.8.5
Assigned To: DJ Delorie
: documentation
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-15 15:37 UTC by roger
Modified: 2014-12-19 13:24 UTC (History)
4 users (show)

See Also:
Host: mips-sgi-irix6.5
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
test patch (643 bytes, patch)
2007-11-01 16:03 UTC, DJ Delorie
Details | Diff
test patch 2 (11.21 KB, patch)
2007-11-01 20:02 UTC, DJ Delorie
Details | Diff
Default libgcc.a objects on mips-sgi-irix6.5 (25.34 KB, text/plain)
2007-11-02 16:41 UTC, roger
Details
test patch 3 (10.16 KB, patch)
2007-11-02 18:56 UTC, DJ Delorie
Details | Diff
sclsh - short command line shell (352 bytes, text/plain)
2007-11-02 18:58 UTC, DJ Delorie
Details
patch to build libraries piecewise (2.80 KB, patch)
2008-06-09 18:41 UTC, Ralf Wildenhues
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description roger 2007-10-15 15:37:21 UTC
The recent addition of a large number of libgcc objects (for fixed point arithmetic and other things) now breaks bootstrap on IRIX.  The problem is
that the command line in libgcc/Makefile.in, approx line 697 reads as:

        $(AR_CREATE_FOR_TARGET) $@ $$objects

which doesn't defend against $objects being a huge list.  Currently on 32-bit
IRIX this is 1762 files.  Indeed, even typing "ls *.o" in the directory
mips-sgi-irix6.5/32/libgcc, returns "-bash: /usr/bin/ls: Arg list too long"!

Alas I'm not a wizard in build machinery, but I suspect that all that's
required is a one or two line change, perhaps to use "libtool" to create the
archive, which contains logic to circumvent these host command line limits.
I believe this is what we currently do for libgcj and other large libraries.

Many thanks in advance to the kind build maintainer or volunteer who looks
into the problem.  I'm happy to test patches on my dusty MIPS/IRIX box.
Comment 1 Jakub Jelinek 2007-10-30 14:01:28 UTC
Untested patch that could help:
--- libgcc/Makefile.in  2007-09-28 08:29:29.000000000 +0200
+++ libgcc/Makefile.in  2007-10-30 14:55:38.000000000 +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?
Comment 2 Jakub Jelinek 2007-10-30 14:03:34 UTC
Actually, that would need to be for f in $$objects; do echo $$f; done | xargs $(AR_FOR_TARGET) $@
Sorry.
Comment 3 DJ Delorie 2007-11-01 16:03:21 UTC
Created attachment 14453 [details]
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.
Comment 4 roger 2007-11-01 17:15:13 UTC
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.
Comment 5 DJ Delorie 2007-11-01 20:02:42 UTC
Created attachment 14457 [details]
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.
Comment 6 Jakub Jelinek 2007-11-01 22:26:12 UTC
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.
Comment 7 Jakub Jelinek 2007-11-01 22:35:29 UTC
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.
Comment 8 roger 2007-11-02 16:41:50 UTC
Created attachment 14471 [details]
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
--
Comment 9 roger 2007-11-02 17:12:02 UTC
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
--
Comment 10 DJ Delorie 2007-11-02 17:41:14 UTC
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.
Comment 11 Jakub Jelinek 2007-11-02 18:40:50 UTC
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.
Comment 12 DJ Delorie 2007-11-02 18:56:20 UTC
Created attachment 14472 [details]
test patch 3

This one just breaks up #15 into three chunks, with everything else in a single chunk.
Comment 13 DJ Delorie 2007-11-02 18:58:13 UTC
Created attachment 14473 [details]
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.
Comment 14 Francois-Xavier Coudert 2008-01-31 10:38:43 UTC
(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?
Comment 15 Roger Sayle 2008-02-01 17:42:38 UTC
Subject: Bug 33781

Author: sayle
Date: Fri Feb  1 17:41:48 2008
New Revision: 132047

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=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

Comment 16 Joseph S. Myers 2008-03-15 00:41:58 UTC
Update milestone after 4.3.0 release.
Comment 17 Richard Biener 2008-06-06 14:58:08 UTC
4.3.1 is being released, adjusting target milestone.
Comment 18 Ralf Wildenhues 2008-06-09 08:33:56 UTC
AFAICS this bug has a workaround patch applied, and may be worked around
by modifying IRIX default settings.

Are you still interested in a proper fix that avoids manual chunking?
It looks like the write_entries_to_file tricks in libjava/Makefile.am
can be applied in this case as well.  Should I look into it?
Comment 19 Ralf Wildenhues 2008-06-09 18:41:57 UTC
Created attachment 15743 [details]
patch to build libraries piecewise

This patch assumes that libgcc_eh.a is the only one of the three libraries
whose list of objects may be empty.  If that assumption is false, then the
other *-objects need to be defaulted as well (but in that case the original
rules had a race condition, not guarding against eh_dummy.[co] being created
concurrently).
Comment 20 roger 2008-06-12 21:31:01 UTC
Hi Ralf,

Thanks for your patch.

Sorry for the delay in replying, I needed to check out mainline on my IRIX
box and rebuild a baseline, and once that had completed "make -k check",
I tried with "--enable-fixed-point" first without, and then with your
patch.  The good news is that this allows the libgcc build to get further,
but unfortunately the bad news is that we die just a little further on with
a similar "execvp: /bin/sh: Arg list too long".

This second failure is where we run nm on all of the objects and pipe the results through mkmap-flat.awk to create tmp-libgcc.map.  This looks to be
in the same libgcc/Makefile.in in the libgcc.map rule (when SHLIB_MKMAP is
defined).

I do like your PR33781.diff patch which moves us in the right direction.
Is it possible/safe to apply similar voodoo to the libgcc.map rule?

Many thanks again for your help.  I've no personal interest in using fixed
point arithmetic on the MIPS, but resolving this issue on IRIX helps keep
the build machinery portable.  If it's not IRIX now, it'll be some other
platform with a low MAXARGS limit in the near future.

Roger
--
Comment 21 Ralf Wildenhues 2008-06-12 21:46:14 UTC
Subject: Re:  [4.3/4.4 Regression] "Arg list too long"
	building libgcc.a

* roger at eyesopen dot com wrote on Thu, Jun 12, 2008 at 11:31:02PM CEST:
> that we die just a little further on with
> a similar "execvp: /bin/sh: Arg list too long".
> 
> This second failure is where we run nm on all of the objects and pipe the
> results through mkmap-flat.awk to create tmp-libgcc.map.

This should be fixable likewise.  I will prepare a patch this weekend.
(I can't test it reliably as the only IRIX system I have access to has
its command line length limit lifted higher, and thus does not fail.)

Cheers,
Ralf
Comment 22 Ralf Wildenhues 2008-06-14 07:25:28 UTC
(In reply to comment #20)
> I do like your PR33781.diff patch which moves us in the right direction.
> Is it possible/safe to apply similar voodoo to the libgcc.map rule?

I suppose the same is necessary for the libgcc_s$(SHLIB_EXT) rule.
Any other rules?  I guess using an options @FILE will be easiest to get around
the limit here.
Comment 23 Joseph S. Myers 2008-08-27 22:02:54 UTC
4.3.2 is released, changing milestones to 4.3.3.
Comment 24 Richard Biener 2009-01-24 10:19:58 UTC
GCC 4.3.3 is being released, adjusting target milestone.
Comment 25 Paul H. Hargrove 2009-04-07 20:39:48 UTC
Has any progress been made on this bug?
I have hit this problem with gcc-4.3.2 on IRIX with both --disable-fixed-point and --disable-decimal-float.  Since this bug is open with a milestone of 4.3.4 I figured a switch to 4.3.3 was not likely to be productive.

However, I thought I would share the fact that I was able to make a little bit of progress beyond what is described in the bug report.

The comment #21 from Ralf Wildenhues suggests he was about to fix the rule for libgcc.map, but nothing appears about such a fix in the bug report.  So, on my own I was able to hack up the libgcc.map rule (in a way not suitable for general use) to get past the failure described in comment #20.

Once past building libgcc.map, however, I find that the rule to build libgcc_s.so is again hitting ARG_MAX, this time in the "xgcc ... -shared" command to build the .so.  I gave up at that point, being uncertain how to automate the incremental construction of a .so (other than by using libtool).
Comment 26 Ralf Wildenhues 2009-04-07 20:46:09 UTC
(In reply to comment #25)
> Has any progress been made on this bug?

No, sorry.  I hit other places that needed this, too, and don't know how to
work around them easily.

As a workaround, can't you raise the limit in the kernel, wasn't that easily
configurable on IRIX?
Comment 27 Paul H. Hargrove 2009-04-07 23:39:24 UTC
(In reply to comment #26)
Ralph,
  Thanks for the quick reply.

Unfortunately, I am not in control of the machine in question and thus cannot raise the ARG_MAX limit on my own.  I will send email to the admins to see if I can have it done.

Since my earlier comment in bugzilla, I have successfully built gcc-4.3.3.  This success was a surprise to me since libgcc/Makefile.in had not changed between 4.3.2 and 4.3.3.  Noting that my 4.3.3 build was in a different directory structure, I retried by build of 4.3.2 in a similar structure and was pleasantly surprised to see that it too ran to completion.

So, while this issue may still be a problem for some people, I believe I may have resolved my own problems by simply using shorter paths for the srcdir and blddir!  I am rerunning some experiments to confirm this.
Comment 28 Richard Biener 2009-08-04 12:28:30 UTC
GCC 4.3.4 is being released, adjusting target milestone.
Comment 29 Richard Biener 2010-05-22 18:11:45 UTC
GCC 4.3.5 is being released, adjusting target milestone.
Comment 30 Richard Biener 2011-06-27 12:12:02 UTC
4.3 branch is being closed, moving to 4.4.7 target.
Comment 31 Jakub Jelinek 2012-03-13 12:44:49 UTC
4.4 branch is being closed, moving to 4.5.4 target.
Comment 32 Jakub Jelinek 2013-04-12 15:15:34 UTC
GCC 4.6.4 has been released and the branch has been closed.
Comment 33 Richard Biener 2014-06-12 13:41:18 UTC
The 4.7 branch is being closed, moving target milestone to 4.8.4.
Comment 34 Jakub Jelinek 2014-12-19 13:24:20 UTC
GCC 4.8.4 has been released.