[Bug bootstrap/33781] New: [4.3 Regression] "Arg list too long" building libgcc.a

[Bug bootstrap/33781] New: [4.3 Regression] "Arg list too long" building libgcc.a

[roger at eyesopen dot com]

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.


-- 
           Summary: [4.3 Regression] "Arg list too long" building libgcc.a
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: roger at eyesopen dot com
  GCC host triplet: mips-sgi-irix6.5


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]

-- 

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

[Bug bootstrap/33781] [4.3 Regression] "Arg list too long" building libgcc.a

[jakub at gcc dot gnu dot org]

------- 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.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?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781

[Bug bootstrap/33781] [4.3 Regression] "Arg list too long" building libgcc.a

[jakub at gcc dot gnu dot org]

------- 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

[dj at redhat dot com]

------- 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=14453&action=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

[roger at eyesopen dot com]

------- 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

[dj at redhat dot com]

------- 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=14457&action=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

[jakub at gcc dot gnu dot org]

------- 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

[jakub at gcc dot gnu dot org]

------- 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

[roger at eyesopen dot com]

------- 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=14471&action=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

[roger at eyesopen dot com]

------- 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

[dj at redhat dot com]

------- 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

[jakub at gcc dot gnu dot org]

------- 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

[dj at redhat dot com]

------- 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=14472&action=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

[dj at redhat dot com]

------- 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=14473&action=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

[mmitchel at gcc dot gnu dot org]

-- 

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

[fxcoudert at gcc dot gnu dot org]

------- 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

[sayle at gcc dot gnu dot org]

------- 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=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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781

[Bug bootstrap/33781] [4.3/4.4 Regression] "Arg list too long" building libgcc.a

[jsm28 at gcc dot gnu dot org]

------- Comment #16 from jsm28 at gcc dot gnu dot org  2008-03-15 00:41 -------
Update milestone after 4.3.0 release.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.0                       |4.3.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781

[Bug bootstrap/33781] [4.3/4.4 Regression] "Arg list too long" building libgcc.a

[rguenth at gcc dot gnu dot org]

------- Comment #17 from rguenth at gcc dot gnu dot org  2008-06-06 14:58 -------
4.3.1 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.1                       |4.3.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781

[Bug bootstrap/33781] [4.3/4.4 Regression] "Arg list too long" building libgcc.a

[Ralf dot Wildenhues at gmx dot de]

------- Comment #18 from Ralf dot Wildenhues at gmx dot de  2008-06-09 08:33 -------
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?


-- 

Ralf dot Wildenhues at gmx dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Ralf dot Wildenhues at gmx
                   |                            |dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781

[Bug bootstrap/33781] [4.3/4.4 Regression] "Arg list too long" building libgcc.a

[Ralf dot Wildenhues at gmx dot de]

------- Comment #19 from Ralf dot Wildenhues at gmx dot de  2008-06-09 18:41 -------
Created an attachment (id=15743)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15743&action=view)
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).



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781

[Bug bootstrap/33781] [4.3/4.4 Regression] "Arg list too long" building libgcc.a

[roger at eyesopen dot com]

------- Comment #20 from roger at eyesopen dot com  2008-06-12 21:31 -------
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
--


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781

[Bug bootstrap/33781] [4.3/4.4 Regression] "Arg list too long" building libgcc.a

[Ralf dot Wildenhues at gmx dot de]

------- Comment #21 from Ralf dot Wildenhues at gmx dot de  2008-06-12 21:46 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781

[Bug bootstrap/33781] [4.3/4.4 Regression] "Arg list too long" building libgcc.a

[rwild at gcc dot gnu dot org]

------- Comment #22 from rwild at gcc dot gnu dot org  2008-06-14 07:25 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781

[Bug bootstrap/33781] [4.3/4.4 Regression] "Arg list too long" building libgcc.a

[jsm28 at gcc dot gnu dot org]

------- Comment #23 from jsm28 at gcc dot gnu dot org  2008-08-27 22:02 -------
4.3.2 is released, changing milestones to 4.3.3.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.2                       |4.3.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781

[Bug bootstrap/33781] [4.3/4.4 Regression] "Arg list too long" building libgcc.a

[rguenth at gcc dot gnu dot org]

------- Comment #24 from rguenth at gcc dot gnu dot org  2009-01-24 10:19 -------
GCC 4.3.3 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.3                       |4.3.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781

[Bug bootstrap/33781] [4.3/4.4/4.5 Regression] "Arg list too long" building libgcc.a

[PHHargrove at lbl dot gov]

------- Comment #25 from PHHargrove at lbl dot gov  2009-04-07 20:39 -------
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).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781

[Bug bootstrap/33781] [4.3/4.4/4.5 Regression] "Arg list too long" building libgcc.a

[rwild at gcc dot gnu dot org]

------- Comment #26 from rwild at gcc dot gnu dot org  2009-04-07 20:46 -------
(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?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781

[Bug bootstrap/33781] [4.3/4.4/4.5 Regression] "Arg list too long" building libgcc.a

[PHHargrove at lbl dot gov]

------- Comment #27 from PHHargrove at lbl dot gov  2009-04-07 23:39 -------
(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.


-- 

PHHargrove at lbl dot gov changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |PHHargrove at lbl dot gov


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781

[Bug bootstrap/33781] [4.3/4.4/4.5 Regression] "Arg list too long" building libgcc.a

[rguenth at gcc dot gnu dot org]

------- Comment #28 from rguenth at gcc dot gnu dot org  2009-08-04 12:28 -------
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.4                       |4.3.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781

[Bug bootstrap/33781] [4.3/4.4/4.5/4.6 Regression] "Arg list too long" building libgcc.a

[rguenth at gcc dot gnu dot org]

------- Comment #29 from rguenth at gcc dot gnu dot org  2010-05-22 18:11 -------
GCC 4.3.5 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.5                       |4.3.6


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781