This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug bootstrap/33781] [4.3/4.4 Regression] "Arg list too long" building libgcc.a
- From: "roger at eyesopen dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 12 Jun 2008 21:31:02 -0000
- Subject: [Bug bootstrap/33781] [4.3/4.4 Regression] "Arg list too long" building libgcc.a
- References: <bug-33781-754@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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