I would then just take the GPLed code of this GC library, GPLed code
of readline, cut out the pieces I need, integrate into my interepreter
and call it "interepter features". Thus, according to you, my
GPL-incompatible program would be able to use GPLed code thanks to
the simple virtue of my program being "interepted".
Voila! GPL is uselless.
There exists java.lang.System.mapLibraryName() pure java method.
This method calls java.lang.NativeLibrary.getLibPrefix() and
java.lang.NativeLibrary.getLibSuffix() methods, but they are NATIVE
methods, and are implemented by ./libraries/clib/native/NativeLibrary.c
file, which is part of kaffe, and therefore available under the GPL.
Therefore only the second case mentioned in the FSF FAQ applies.
http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
"However, when the interpreter is extended to provide "bindings" to
other facilities (often, but not necessarily, libraries), the
interpreted program is effectively linked to the facilities it uses
through these bindings. So if these facilities are released under the
GPL, the interpreted program that uses them must be released in a
GPL-compatible way. The JNI or Java Native Interface is an example of
such a binding mechanism."