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

2009-01-24 Thread 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 Regression] Arg list too long building libgcc.a

2008-08-27 Thread 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

2008-06-14 Thread 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

2008-06-12 Thread 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

2008-06-12 Thread 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

2008-06-09 Thread 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

2008-06-09 Thread 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=15743action=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

2008-03-14 Thread 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