making static linkage useful (oh the horror!)

Fri Jan 17 11:02:00 GMT 2003

Adam Megacz writes:
 > 
 > Andrew Haley <aph@redhat.com> writes:
 > > > The -fno-bounds-check option "breaks" gcj by deviating from the JLS,
 > > > yet we still allow it.
 > 
 > > Uh, sure. I don't think there is any way to implement
 > > -fno-bounds-check without deviating from the JLS.
 > 
 > I can prove that there is no way to implement static linkage without
 > deviating from the JLS.
We've already established that.
 > Now is it okay to include static linkage?
We already include it.
 > > > Why is -fno-bounds-check okay, but not-fully-JLS-compliant
 > > > static linkage isn't?
 > 
 > > Well, -fno-bounds-check doesn't disable any APIs.
 > 
 > Sure it does; any APIs that explicitly depend on
 > ArrayBoundsCheckException will break. Specifically, JVM security
 > goes straight out the window, so java.lang.Security is completely
 > pointless (hence, "broken").
-fno-bounds-check breaks the JLS, but we already know that. I don't
see the point of arguing about this, since we agree.
 > > Besides, -fno-bounds-check is IMO not okay: AFAIK it's really a
 > > kludge because we don't eliminate array bounds checks in the
 > > compiler. We should fix that.
 > 
 > Huh? How could you eliminate bounds checks without deviating from the
 > JLS? The JLS *requires* bounds checks.
Not at all; it requires programs to behave _as if_ bounds checking
were done. The better JITs around eliminate these bounds checks
whenever they can, but gcj doesn't and hence -fno-bounds-check is a
win.
 > Your argument that "X deviates from the JLS therefore we must not
 > offer X as an off-by-default option" is completely bogus.
I have never made any such argument.
My argument has never been that we must not provide static linkage,
because we already do. However, the current "support" for static
linkage breaks a great deal of the API. This is bad.
Also, it breaks the API in a bunch of places and we don't even have a
list of them. 
I've been thinking about a way to make things a little more sane.
What we might be able to do is, when linking, detect a reference to
any of the APIs that depend on dynamic libraries and issue a warning.
This would solve the support problem in most cases. At the moment I'm
not quite sure how to do this.
Andrew.