Re: 116v2-glibc / libdl and JNI
actually, library calls are over-rided, not system-calls. If u are savey enough, u can call the system service yourself, and forget the library interface ( ie instead of using select, try __select ). But in doing so, the green threading ( fake threads ) can be comprimised, ie other threads wont be runnable until that service completes. the malloc/free bogus ptrs messages are problems in trying to free a pointer twice, of which some "MALLOC" pkgs get terminally upset with. I guess in ur case, i guees it was time to say enough allready :-) gat Juergen Kreileder wrote: > > > You know that that the JNI Invocation API is documented not to work > with green threads? > The green threads' libjava.so overrides some system calls, so the > first thing in a green threads program must be creating the vm otherwise > system calls like open() will not work properly. > > Y
Re: 116v2-glibc / libdl and JNI
Juergen Kreileder writes: > > Classpath default: > >/../../../classes:/../../classes.zip:/../../classes.jar: > Yes, you have to tell the VM where it can find classes.zip. Could this please be clarified? a) the classpath generated by the JVM is bogus, right? If anything, it should be relative to it's location, e.g. /usr/local/java/lib? b) from the jdk1.1.6/README.linux: No CLASSPATH, no JAVA_HOME, or other environment variables to set to get the basic system running. Now, I am not using the bin/ scripts when I do JNI. Is my CLASSPATH environment variable totally ignored here? b.
Re: help me
On Mon, 22 Jun 1998, Cho Hui Dae wrote: > hi! can you help me? i have the following error whenever i run > every programs included in linux jdk 1.1.6. what happened? > first of all, i got "Segmentation fault" with libc library in > jdk. so i removed it coz i have already installed the same version > of libc. then i can run some programs. but they didn't work with > this error. please help me. i couldn't subscribe [EMAIL PROTECTED] > coz mail returned to me. mail server couldn't find it's id. > help me. and sorry for my lame english you need to install version 1.9.6 (or lower) of ld.so. I was getting the same errors and did that and it worked fine. Others have reported the same thing... One caveat: after installing ld.so.1.9.6, when you restart ld-linux.so.1 will STILL be pointing to ld-linux.so.1.9.9. I have to manually change the link to ld-linux.so.1.9.6 EVERY TIME I RESTART. The same goes for libdl.so.1 (after restart it points to libdl.so.1.9.9 and I have to make it point to libdl.so.1.9.6). be EXTREMELY careful when doing this or you can hose your ENTIRE COMPUTER and have to fix it from a boot disk (thats what I did)... if you wan more specific instructions, just ask... Michael Plump | Snorks make me smile, okay? eh | [EMAIL PROTECTED] "Frankly, I don't know where such independent monkey ringers come from." --Joe Dietz
Re: 116v2-glibc / libdl and JNI
Bernd Kreimeier <[EMAIL PROTECTED]> writes: > Juergen Kreileder writes: > > > Classpath default: > > >/../../../classes:/../../classes.zip:/../../classes.jar: > > Yes, you have to tell the VM where it can find classes.zip. > > Could this please be clarified? > > a) the classpath generated by the JVM is bogus, right? >If anything, it should be relative to it's location, > e.g. /usr/local/java/lib? /../../../classes:/../../classes.zip:/../../classes.jar: is not a very useful classpath ;-) With that classpath the vm cannot find classes.zip and will fail with: Unable to initialize threads: cannot find class java/lang/Thread > > b) from the jdk1.1.6/README.linux: > No CLASSPATH, no JAVA_HOME, or other environment > variables to set to get the basic system running. >Now, I am not using the bin/ scripts when I do JNI. >Is my CLASSPATH environment variable totally ignored >here? Afaik the enviroment CLASSPATH is ignored when you use the JNI Invocation API (CLASSPATH isn't important for ordinary JNI). CLASSPATH usually doesn't contain the path to classes.zip, that part of CLASSPATH is set by the .java_wrapper script. When you use Invocation you should override the classpath returned by JNI_GetDefaultJavaVMInitArgs. The classpath must include the path to classes.zip and the path to your own classes/zip-/jar-archives. If you want to use environment variables for setting the classpath you can use char* getenv(const char* name). Jürgen -- Juergen Kreileder, Universitaet Dortmund, Lehrstuhl Informatik V Baroper Strasse 301, D-44221 Dortmund, Germany Phone: ++49 231/755-5806, Fax: ++49 231/755-5802
help me
hi! can you help me? i have the following error whenever i run every programs included in linux jdk 1.1.6. what happened? first of all, i got "Segmentation fault" with libc library in jdk. so i removed it coz i have already installed the same version of libc. then i can run some programs. but they didn't work with this error. please help me. i couldn't subscribe [EMAIL PROTECTED] coz mail returned to me. mail server couldn't find it's id. help me. and sorry for my lame english Regards, Huidae Cho [EMAIL PROTECTED] === SIGSEGV 11* segmentation violation Full thread dump: Monitor Cache Dump: Registered Monitor Dump: Monitor IO lock: Child death monitor: Event monitor: I/O monitor: Alarm monitor: Monitor registry: Thread Alarm Q: ===
Textfield's don't work in the glibc-version of jdk1.1.6x
I haven't managed to get a Textfield display any character in any font at all using the glibc-version of jdk1.1.6x. Using the libc5-version everything works (even swedish characters are displayed correctly now), so it seems like it's something specific to the glibc-version. Marcus Isaksson
JDK 1.1.6v2 broken - SEGVs
Had this problem with both JDK 1.1.6v1 and v2. 1.1.5v7 works wonderfully, though. And btw, the JRE is broken on v2 - can't load libjava. It gives the full path to libjava.so (the correct path) but it says it can't load it. Thought I'd let ya know... I know it can't be my libc, since it's using a private copy of libc. :) Let me know... Thanks. Derrik Pates [EMAIL PROTECTED] [EMAIL PROTECTED]
