This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bytecode verifier


>  > It is a Good Thing, IMHO, but I'm just confused by
>  > how you did it, especially after I remember us being
>  > reticent to even use libiberty in libgcj and by the
>  > order in which I see different parts of the GCC tree being
>  > configured and built (libiberty, front-ends, libraries).
> 
> libiberty is GPL; libgcj is GPL+exception.  There's no reason to to
> link GPL code with GPL+exception code.

If the front-end bits provide the API for the verifier
and libgcj uses it, it has to link to GPL-ed code, no?

If libgcj provides the API for the verifier and the
front-end uses it, the configury and the build process
should get really weird.

BTW, as has been pointed earlier, Sun's JVM doesn't
even bother verifying classes loaded locally unless
you use the "-verify" flag, so maybe even we ought
not to bother by default. A runtime flag/environment-
variable/property should at least help in not having
to comment out the verifier call and recompiling
libgcj in order to get an application working.

Ranjit.

-- 
Ranjit Mathew          Email: rmathew AT hotmail DOT com

Bangalore, INDIA.      Web: http://ranjitmathew.tripod.com/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]