This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
input line is too long
- From: "Erik Poupaert" <erik dot poupaert at chello dot be>
- To: <java at gcc dot gnu dot org>
- Date: Tue, 31 Dec 2002 11:29:35 +0100
- Subject: input line is too long
>>>> See natRuntime.cc:_Jv_FindSymbolInExecutable to see exactly how
>>>> symbols are found at runtime. Basically we iterate over all known
>>>> libraries and ask libltdl about them.
If the lookup fails, we could ask natruntime.cc to continue querying, but
then from the executable's own symbols and try to resolve the JNI symbol's
address from there? On the condition that there is some multiplatform
version of such query, because, for example, nlist(), seems closely related
to a.out and ELF. But then again, the problem must already have been solved
for GDB. So, I guess the solution does exist somewhere.
Would such patch be added to the mainstream? Or would it potentially have
ugly side-effects?
In the meanwhile I would still have to crosscompile such patched GCJ from
Linux ... This procedure is documented, but I would still have to install
Linux first, somewhere...
But then again, I would personally really appreciate getting rid of these
separate JNI (and CNI?) dlls, and integrate them into the executable's own
body.