Bootstrap fails during libjava on some targets This is apparently due to the extremely long command line of 73,379 characters given to the linker. Though it seems Automake should be able to handle this itself, I would think this could be circumvented by splitting the link into a several convenience libraries and then linking those together. Build output below
Created attachment 6998 [details] First line in attachment is the 73,000+ character linker command
Actually I thought we are already doing this ...
Well, to be honest libjava on darwin < 7.0 does not make much sense. You can only use a subset of the library for very limited functionality. The big part missing is the shared library support. For example all the SWING/AWT part you can't use since the libgcc is statically linked in for several libraries.
Andreas, can we document the "minimum Darwin 7.x" requirement somewhere - perhaps install.texi? Perhaps we should also set up configure to only build libjava by default on Darwin >= 7.0. Bryce
oh, now I seem to remember why shared libraries are not supported under darwin < 7.0. Afair it was due to the missing MD_FALLBACK_FRAME_STATE_FOR macro at the time when I introduced the changes for shared libraries on darwin. Now this macro is in and it should also support darwin < 7.0. You may try to modify ltcf-c.sh, ltcf-cxx.sh, ltcf-gcj.sh and ltconfig in the toplevel gcc dir. See where it says: case $host_os in darwin[1-6]*) can_build_shared=no ;; darwin7*) can_build_shared=yes ;; esac To say yes for darwin6.x too. It may help. I don't know since I no longer have a 6.x machine around. Just an idea.
a) Changing the lt* scripts had no effect. b) This problem also happens under cygwin.
The original thread has a patch: http://gcc.gnu.org/ml/gcc/2004-09/msg01301.html
The patch fixes the problem on cygwin. On its face it certainly appears that it would also fix the problem under the older OS X versions. I recently upgraded my iMac to OS X 10.3, so I can't test it there. Perhaps Lars could help as he also reported the problem. As the initiator of the PR, I would support its closing upon installation of the patch.
Subject: Bug 17222 CVSROOT: /cvs/gcc Module name: gcc Changes by: tromey@gcc.gnu.org 2004-09-28 20:37:45 Modified files: libjava : ChangeLog Makefile.am Makefile.in Log message: PR libgcj/17222: * Makefile.am (libgcj.la): Restored. * Makefile.in: Rebuilt. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3101&r2=1.3102 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/Makefile.am.diff?cvsroot=gcc&r1=1.416&r2=1.417 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/Makefile.in.diff?cvsroot=gcc&r1=1.444&r2=1.445
Fix checked in. Thanks Kelley.
> Perhaps Lars could help as he also reported the problem. I'll test that by the time the next weekly snapshot of head is out.
I successfully bootstrapped gcc-4.0-20041003 on Mac OS X 10.2.8 (powerpc-apple-darwin6.8). This bugg seems to be fixed here too. see: http://gcc.gnu.org/ml/gcc/2004-10/msg00379.html
This bootstrap bug unfortunately became re-introduced with this Richard Henderson patch which moved the command line linking the thousands of sources directly from libgcj.la to a convenience library libgcj0_convenience_la. This commandline happens to be 94,720 characters long which exceeds reasonable expectations. http://gcc.gnu.org/ml/java-patches/2005-q1/msg00402.html This should be pretty straightforeward to fix by moving Tom Tromey's previous clever hack to the new convenience library. I'll try that and report back the results.
Created attachment 8313 [details] The new huge command line after the rth patch
This was filed under PR 20155. The orginal problem was fixed but showed up again via soemthing. Next time open a new bug instead of reopening this one.