This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Are non-SJLJ exceptions busted on linux/x86?
- From: Andrew Pinski <pinskia at physics dot uc dot edu>
- To: scottg at mantatest dot com (Scott Gilbertson)
- Cc: pinskia at physics dot uc dot edu (Andrew Pinski), gnustuff at thisiscool dot com (Mohan Embar), java at gcc dot gnu dot org
- Date: Thu, 17 Nov 2005 16:57:54 -0500 (EST)
- Subject: Re: Are non-SJLJ exceptions busted on linux/x86?
> A) Because it claims to be supported (i.e. the commands are there to do it)
But if you go look through bug reports there are already one or two which
says this will never be supported.
> B) Because that's what you usually want if you're building embedded systems
> (as I am)
Usually for small embedded systems yes. But if you are using GCJ and X11,
I am going to assume you are not building one of those. If you take
a look at the file sizes you will notice that you are duplicating a lot
of symbols and maybe you should rethink using shared libraries.
> C) Because you can't really claim it's a proper native code compiler if it
> can't do a simple thing like a static build
Huh? Note a lot of functionality in glibc cannot be done using static libraries
so where is the difference?
> D) Because one of the main reasons I selected GCJ was for that capability
For static linking? HUH? Why not use C, I don't see the issue.
> E) Because early in my involvement, I read articles like this one:
> http://www.linuxjournal.com/article/4860
> (Quote: "We view Java as simply another programming language and
> implement it the way we implement other compiled languages.")
It does not talk about static linking at all. Also I mentioned above even
glibc is making the depencies on dynamic linking.
> F) Because someday gcj might work for no-filesystem environments, but only
> if it can make a static binary
That is a hard thing to do as java is a class/file based system.
> G) Because static builds worked until maybe July or August of this year and
> are now broken
Actually they never worked really. Go look back in the archives and you will
> H) Because failure of static binaries to run is a regression from earlier
> released gcc versions.
See my answer to G. I can find bugs about it not working too.
> I) Because according to this email it's the only way to run on MS Windows
> http://gcc.gnu.org/ml/java/2005-11/msg00238.html
Win32 issues are a different problem. Win32 builds of gcj are moving to dynamic
libraries soon.
One more thing, Objective-C really has the same issues as gcj and static
linking as both are very dynamic languages and can load classes at runtime
via a string which is why static linking will never work correctly with
java and Objective-C.
Thanks,
Andrew Pinski