From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Boehne To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org Subject: Re: libgcj/1736 Date: Sun, 01 Apr 2001 00:00:00 -0000 Message-id: <20010306142600.20928.qmail@sourceware.cygnus.com> X-SW-Source: 2001-q1/msg02045.html List-Id: The following reply was made to PR libgcj/1736; it has been noted by GNATS. From: Robert Boehne To: Bryce McKinlay Cc: gcc-gnats@gcc.gnu.org, David.Billinghurst@riotinto.com, java@gcc.gnu.org, libtool@gnu.org Subject: Re: libgcj/1736 Date: Tue, 06 Mar 2001 08:22:34 -0600 Bryce: I submitted two patches to fix the "Arg length too long" problems. The first will work around link lines created by libtool that are too long to execute, the second uses the -objectlist FILE option in link mode to allow a file containing a list of *.lo objects rather than the list of objects itself. These patches have only been committed to the multi-language-branch at this time, but could be applied to the MAIN/HEAD branch as well. The -objectlist patch was committed yesterday, so you probably just need an update. Robert Bryce McKinlay wrote: > > Synopsis: [irix 6.5] Cannot create libgcj - Arg list too long > > Okay, it appears that libtool has recently got the feature we need: > > 2001-02-22 Robert Boehne > > * ltconfig.in: Add a test to find the approximate limit > to the length of command line arguments. The number > calculated here should always be lower than the actual > limit. > * ltmain.in: Test the length of the command line to be > executed and use an incremtnal linking scheme if the > command is too long to be interpreted without error. > * doc: Test the length of the command line to be > executed and use an incremtnal linking scheme if the > command is too long to be interpreted without error. > * doc/libtool.texi (Reloadable Objects): Added a few > sentences to describe how piecewise linking is done > for shared objects by creating reloadable object files. > > So, I installed the latest libtool into my gcc tree, which sort-of > works, and happily incrementally linked a bunch of libgcj-1.la... > libgcj-2.la... etc files when I hacked it to think that it could only > use short command lines. > > (Side note/bug report: on the last one it got: > > ld: unrecognized option `-Wl,--whole-archive' > ld: use the --help option for usage information > > So, it's trying to pass the compiler -Wl flag directly to the linker > for some reason. I hacked the libtool script a bit and everything > worked.) > > But then I realised that this doesn't help us at all - regardless of > what libtool does the command line that _make_ is passing to libtool > is still too long! The only realistic solutions I can think of are to > 1) adapt the build to use GCJ's multi-file compilation and have it > make one .o per package or something. Unfortunately, by doing that > we'd lose fine-grained dependency tracking amongst the java files, but > maybe the speed gain from multi-file compilation would at least > partially offset that loss. 2) Somehow pass the list of files to link > to libtool in a file rather than on the command line. I guess that > would also require an automake upgrade/change? > > As a workaround for now, I'd suggest removing .java files from the > build that you don't need (AWT classes for example). Presumably, given > that it worked in the last release, we arn't all that far over IRIX's > limits. Alternatively, maybe you could install a less brain dead > shell? ;-) > > regards > > [ bryce ] > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1736&database=gcc -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: rboehne@ricardo-us.com