This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Remaining Itanium exception, static linking patches
- From: Tom Tromey <tromey at redhat dot com>
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Cc: "'java-patches at gcc dot gnu dot org'" <java-patches at gcc dot gnu dot org>
- Date: 14 Mar 2002 12:50:16 -0700
- Subject: Re: Remaining Itanium exception, static linking patches
- References: <40700B4C02ABD5119F000090278766443BF08F@hplex1.hpl.hp.com>
- Reply-to: tromey at redhat dot com
>>>>> "Hans" == Boehm, Hans <hans_boehm@hp.com> writes:
Hans> The last patch shouldn't be checked in. It has nothing to do
Hans> with Itanium, but is a stopgap to allow me to link SPECjbb
Hans> statically, which unfortunately makes a substantial performance
Hans> difference. It was suggested by someone else (Bryce?) I post
Hans> it here for discussion, since I'm not sure there will be another
Hans> solution in 3.1, and I think it is still a real issue. Is there
Hans> a better (e.g. less US-centric) solution we could get into 3.1?
This is one of those places where static linking falls down.
I don't know of a better fix. We could force all the locale files to
be linked in. That's pretty extreme though.
Bryce noted that we'd save a lot of space if we used property files
for locale data (built with gcj -R) instead of classes like we do now.
That's definitely on the to-do list. This might help with static
linking, but it amounts to linking everything in.
Tom