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]

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.



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