From mboxrd@z Thu Jan 1 00:00:00 1970 From: ptf@ftel.co.uk To: gcc-gnats@gcc.gnu.org Subject: libgcj/1758: java.util package lacks TreeMap Date: Sun, 01 Apr 2001 00:00:00 -0000 Message-id: <20010124164109.15994.qmail@sourceware.cygnus.com> X-SW-Source: 2001-q1/msg00669.html List-Id: >Number: 1758 >Category: libgcj >Synopsis: java.util package lacks TreeMap >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: change-request >Submitter-Id: net >Arrival-Date: Wed Jan 24 08:46:03 PST 2001 >Closed-Date: >Last-Modified: >Originator: ptf@ftel.co.uk >Release: 2.97 >Organization: >Environment: Reading specs from /opt/gcc-snap/lib/gcc-lib/i686-pc-linux-gnu/2.97/specs Reading specs from /opt/gcc-snap/lib/gcc-lib/i686-pc-linux-gnu/2.97/../../../libgcj.spec rename spec lib to liborig rename spec startfile to startfileorig Configured with: ../gcc/configure --prefix=/opt/gcc-snap --enable-languages=c,c++,java gcc version 2.97 20010124 (experimental) >Description: As summary. >How-To-Repeat: n/a >Fix: The classpath-0.02 implementation drops in and compiles OK - I don't yet know whether it works - I'm trying to build a large app with gcj and I don't have all of the components compiled yet. >Release-Note: >Audit-Trail: >Unformatted: >>From bryce@waitaki.otago.ac.nz Sun Apr 01 00:00:00 2001 From: Bryce McKinlay 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: <20010306070601.25930.qmail@sourceware.cygnus.com> X-SW-Source: 2001-q1/msg02041.html Content-length: 2905 The following reply was made to PR libgcj/1736; it has been noted by GNATS. From: Bryce McKinlay To: gcc-gnats@gcc.gnu.org, David.Billinghurst@riotinto.com, nobody@gcc.gnu.org, java@gcc.gnu.org, rboehne@ricardo-us.com, libtool@gnu.org Cc: Subject: Re: libgcj/1736 Date: Tue, 06 Mar 2001 20:07:49 +1300 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