Re: JNI problem

1998-05-11 Thread Robert Lynch

Mark Fardal wrote:
> 
> > What happens if you use the debug version of the java interpreter (java_g)?
> >
> > Steve
> >
> 
> The result is the same as was reported with 1.1.5, it reads a single string
> and returns fine.
> 
> weka:native[ 996 ] java_g Prompt
> Type a line: hi there
> A diagnostic message...
> User typed: hi
> 
> This is correct behavior I believe, the example only reads a single
> string (%s).  Odd that the debug version changes the behavior but
> it's nice to know the easy workaround.
> 
> Thanks,
> Mark Fardal
> UMass

Hi-

I reported that 1.1.5v7 works OK, so I was interested and tried this
also. However, I get the strange (?) behavior that it then expects the
shared libary to end in "_g":

[user@ravel native]$ java_g Prompt
libMyImpOfPrompt_g.so: cannot open shared object file: No such file or
directory (libMyImpOfPrompt_g.so)

when I compile the C code to a shared library named
"libMyImpOfPrompt_g.so" it then works:

[user@ravel native]$ java_g Prompt
Type a line: Hi there
User typed: Hi there

(I've also altered the original "scanf" code to get user input up to a
'\n').

Bob L.
-- 
Robert Lynch-Berkeley CA [EMAIL PROTECTED]
http://www.best.com/~rmlynch/




Re: java.lang.System$DelegatingPrintStream

1998-05-11 Thread Joshua Pollak

JavaSoft's VM uses native methods to modify the public static final
System.in, .out, and .err fields. The java-linux port has a modified
System.java which uses the inner-class DelegatingPrintStream to get around
this, but causes an incompatibility between code based on the behavior of
Sun's VM and Linux's. 

I got around the problem by editing and compiling my own
java.lang.System, making in, out, and err non-final fields, and
changing their initialization & set methods.

I've attatched the sample code that breaks the java-linux System class if
you want to look at it.

BTW: I agree with the author of DelegatingPrintStream et al. that this was
a terrible way of implementing public-read/private-write on the part of
Sun.

Cest la vie...

Joshua Pollak
http://www.pico.org/~josh

On Mon, 11 May 1998, Albert L. Ting wrote:

> Joshua Pollak writes:
> > From: Joshua Pollak <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: java.lang.System$DelegatingPrintStream
> > Date: Mon, 4 May 1998 13:04:08 -0400 (EDT)
> > 
> > 
> > It looks like the intent of "DelegatingPrintStream" is to cause all
> > references to System.out to point to the current System.out even if the
> > user reassigns System.out. Unfortunately, this is contrary to the behavior
> > of Sun's API.
> > 
> > I'd be interested in hearing why there are diferences between Sun's
> > classes.zip and the one distributed with JDK 1.1.5 for Linux.
> > 
> > FYI, this breaks the logging code in our software.
> > 
> > Thanks for your attention (and great work in porting the JDK).
> > 
> > -josh
> 
> Hi Josh,
> 
>Did you get a response?  I'm having the same problem with jdk1.1.5.
> 
> Thanks,
> Albert
> 
> -- 
> Albert L. M. Ting * [EMAIL PROTECTED] * 408-548-3111 * http://www.artisan.com
> Artisan Components, Inc. * 1195 Bordeaux Drive * Sunnyvale, CA  94089 * USA
> 

here's the code that breaks under java-linux:


import java.io.IOException;
import java.io.FileOutputStream;
import java.io.OutputStream;
import java.io.PrintStream;

public class Redirect extends OutputStream {

  OutputStream out1;
  OutputStream out2;

  public Redirect(OutputStream out1,
  OutputStream out2) {
this.out1 = out1;
this.out2 = out2;
  }

  public void write(int c) throws IOException {
out1.write(c);
out2.write(c);
  }

  public static void main(String[] args) throws Exception {
OutputStream console = System.out;
OutputStream file = new FileOutputStream("file");
Redirect r = new Redirect(console, file);

PrintStream ps = new PrintStream(r);
System.setOut(ps);

console.write("This should go to the console only.\n".getBytes());
console.flush();

file.write("This should go to the file only.\n".getBytes());
file.flush();

ps.print("This should go to the console and file.\n");
ps.flush();

  }

}





For Travis Shirk (more)

1998-05-11 Thread Roger Hill


> Hello Again,
> 
> One last thing.  After updating to libc.5.4.44 I still can't run
> java because it complains about not being able to load libm.so.5
> 
> I don't have a libm.so.5 in /usr/lib or /lib.  There is a link
> in /lib that points libm.so.6 to libm-2.0.6.so.  Do I need
> to make a simalir link?  The onlt link I could think of
> making is libm.so.5 --> libm.so.5.0.9
> 
I am attaching a ls -l of my /lib.  Yes, I would link libm.so.5 to
libm.so.5.0.6 (or 9) and see what happens.

Roger

Roger Hill, P.O.Box 4T, Barbados, West Indies.   E-mail:[EMAIL PROTECTED]
Tel:246-228-5216/230-9596   Fax:246-433-8365 



total 5174
lrwxrwxrwx   1 root root   41 Nov 15 04:47 cpp -> 
../usr/lib/gcc-lib/i386-linux/2.7.2.1/cpp
-rw-r--r--   1 root root0 May 11 17:49 fred
lrwxrwxrwx   1 root root   18 May  3 06:02 ld-linux.so.1 -> 
ld-linux.so.1.7.14
-rwxr-xr-x   1 root root21367 Aug 26  1996 ld-linux.so.1.7.14
lrwxrwxrwx   1 root root   12 May  3 06:02 ld.so -> 
ld.so.1.7.14
lrwxrwxrwx   1 root root   12 May  3 06:11 ld.so.1 -> 
ld.so.1.7.14
-rwxr-xr-x   1 root root24580 Aug 26  1996 ld.so.1.7.14
-rw-r--r--   1 rhillrhill 1197954 Dec  5  1996 libc.a
lrwxrwxrwx   1 root root   14 May  3 06:03 libc.so.5 -> 
libc.so.5.4.33
-rwxr-xr-x   1 root root   706960 Dec  5  1996 libc.so.5.3.12
-rwxr-xr-x   1 root root  1868689 Dec 26 10:12 libc.so.5.4.33
lrwxrwxrwx   1 root root   17 Nov 15 04:47 libcom_err.so.2 -> 
libcom_err.so.2.0
-rwxr-xr-x   1 root root 5819 Sep  1  1996 libcom_err.so.2.0
lrwxrwxrwx   1 root root   15 May  3 06:04 libdl.so -> 
libdl.so.1.7.14
lrwxrwxrwx   1 root root   15 May  3 06:04 libdl.so.1 -> 
libdl.so.1.7.14
-rwxr-xr-x   1 root root 6983 Aug 26  1996 libdl.so.1.7.14
lrwxrwxrwx   1 root root   13 Nov 15 04:47 libe2p.so.2 -> 
libe2p.so.2.1
-rwxr-xr-x   1 root root 8841 Sep  1  1996 libe2p.so.2.1
lrwxrwxrwx   1 root root   16 Nov 15 04:47 libext2fs.so.2 -> 
libext2fs.so.2.0
-rwxr-xr-x   1 root root46800 Sep  1  1996 libext2fs.so.2.0
-rw-r--r--   1 rhillrhill   87248 Dec  5  1996 libm.a
lrwxrwxrwx   1 root root   13 May  9 16:04 libm.so.5 -> 
libm.so.5.0.6
-rwxr-xr-x   1 root root36309 Dec  5  1996 libm.so.5.0.6
lrwxrwxrwx   1 root root   11 Nov 15 04:56 libpam.so -> 
libpam.so.0
lrwxrwxrwx   1 root root   14 Nov 15 04:56 libpam.so.0 -> 
libpam.so.0.54
-rw-r--r--   1 root root67603 Dec 17  1996 libpam.so.0.54
-rw-r--r--   1 root root19106 Dec 17  1996 libpam_misc.a
lrwxrwxrwx   1 root root   16 Nov 15 04:56 libpam_misc.so -> 
libpam_misc.so.0
lrwxrwxrwx   1 root root   19 Nov 15 04:56 libpam_misc.so.0 -> 
libpam_misc.so.0.54
-rw-r--r--   1 root root16389 Dec 17  1996 libpam_misc.so.0.54
lrwxrwxrwx   1 root root   17 May  1 08:09 libpthread.so -> 
libpthread.so.0.6
lrwxrwxrwx   1 root root   17 Dec 26 12:34 libpthread.so.0 -> 
libpthread.so.0.6
-rwxr-xr-x   1 root root57300 Dec 17  1996 libpthread.so.0.5
-rwxr-xr-x   1 root root68705 Jan  3 08:06 libpthread.so.0.6
-rw-r--r--   1 root root   591852 Dec 16  1996 libpwdb.a
lrwxrwxrwx   1 root root   12 Nov 15 04:57 libpwdb.so -> 
libpwdb.so.0
lrwxrwxrwx   1 root root   15 Nov 15 04:57 libpwdb.so.0 -> 
libpwdb.so.0.53
-rw-r--r--   1 root root   295286 Dec 16  1996 libpwdb.so.0.53
lrwxrwxrwx   1 root root   12 Nov 15 04:47 libss.so.2 -> 
libss.so.2.0
-rwxr-xr-x   1 root root18029 Sep  1  1996 libss.so.2.0
lrwxrwxrwx   1 root root   19 Nov 15 04:54 libtermcap.so.2 -> 
libtermcap.so.2.0.8
-rwxrwxr-x   1 root root11419 Jul 28  1996 libtermcap.so.2.0.5
-rwxr-xr-x   1 bin  bin 11293 Dec  9  1996 libtermcap.so.2.0.8
drwxr-xr-x   4 root root 1024 Dec 30 13:18 modules
drwxr-xr-x   2 root root 

For Travis Shirk

1998-05-11 Thread Roger Hill

Your email address bounced:

On Mon, 11 May 1998, Travis Shirk wrote:

> Hello,
> 
> I saw a message of your on the java-linux mailling list, and
> have run into the same problem regarding talk.  You say that
> you reverted to libm.5.0.6 and everything worked.  Couple
> of questions about that:
> 
> Did you change /usr/lib/libm.so to point to /lib/libm.so.5.0.6?
> If so, what does that do for libc.so?  Does'nt it need the
> newer version of libm.so in order to work correctly.

First of all, assume that I don't know much of what I'm talking about :).

When I upgraded libc to 5.4.44, libm 5.0.9 came along with it. So when I
reverted to 5.4.33 (which Steve Byrne says is just fine, BTW), I also had
to revert to libm 5.0.6. In /lib there were both 5.0.9 and 5.0.6;
libm.so.5 was a symbolic link pointing to 5.0.9. I just relinked it to
5.0.6, renamed 5.0.9 to xlibm509 or something, and reran ldconfig. And it
all started to work again!

> 
> If talk won't work with libm.so.5.0.9 then essentially I can
> never upgrade my libm if I want to continue using talk.  Is
> there a way to make talk use a particular version of libm,
> while the standard libm is a sym link to the most current
> version?

I'm sure that if you pull down the sources and recompile talk, it will
work. I did not try that.

> 
> The release notes for libc.5.4.44 say that it is backward 
> compatible with previous versions of libc.  Obvously this
> is not the case for the talk program.
> 
Well, libm seemed to be the problem, not libc.

> When I upgraded my libc it must have wiped out libm.so.5.0.6,
> because I can't find it anywhere.  COuld you possibly send
> me yours?  Assuming that you are running intel Linux, of course.
> 
Sure. Attached.

> Lastly, how did you find out that reverting your libm to 5.0.6
> would fix the problem.  I'd like to be able to detect this myself
> next time ;-).
> 
After much head scratching, I decided that that was the only thing left to
try!



Roger Hill, P.O.Box 4T, Barbados, West Indies.   E-mail:[EMAIL PROTECTED]
Tel:246-228-5216/230-9596   Fax:246-433-8365 


 libm506


jdk1.1.5

1998-05-11 Thread rbarry

I've been trying to get jdk1.1.5 working on my linux system.  I had 1.0
working but every time I try 1.1.5 I get the message
/usr/local/java/bin/java:
/usr/local/java/bin/../bin/i586/green_threads/java: No
 such file or directory   

This message is untrue because I have seen the contents of the directory
and attempted to run java and javac from that directory.
I would appreciate any help or suggestions.
thank you
[EMAIL PROTECTED]




Core dumping.

1998-05-11 Thread Travis Shirk

Hello,

I've recently upgraded to libc.5.4.44 and everytime I run jdk1.1.5
version 6 or 7 (Steve Byrne's port) java core dumps.  When I try
compiling hello world I get a core dump.. When I run javac with 
no arguments I get a core dump (with no output displayed on the screen).

When I installed the new libc I had no problems.  No error or warnings
were displayed and everything is working fine on my system (aside from
talk not working, which is a problem someone else has also run into).

Any ideas?

Travis

--
Travis Shirk
[EMAIL PROTECTED]




JNI problem

1998-05-11 Thread Steve Byrne

Mark Fardal writes:
 > 
 > Hi,
 > 
 > The example (Prompt) of how to pass and return arguments
 > from C routines exits:
 > 
 > weka:native[ 863 ] java Prompt
 > Type a line: hi there
 > SIGSEGV   11*  segmentation violation
 > stackbase=0xb920, stackpointer=0xb7bc
 > 
 > I'm running jdk1.1.3 on Debian Linux 1.3.  The example can be found at
 > http://java.sun.com/docs/books/tutorial/native1.1/implementing/declare.html

What happens if you use the debug version of the java interpreter (java_g)?

Steve




Re: JNI problem

1998-05-11 Thread Mark Fardal



> What happens if you use the debug version of the java interpreter (java_g)?
> 
> Steve
> 

The result is the same as was reported with 1.1.5, it reads a single string
and returns fine.  

weka:native[ 996 ] java_g Prompt
Type a line: hi there
A diagnostic message...
User typed: hi

This is correct behavior I believe, the example only reads a single 
string (%s).  Odd that the debug version changes the behavior but 
it's nice to know the easy workaround.

Thanks,
Mark Fardal
UMass









Re: Linux/Alpha port of JDK

1998-05-11 Thread James Cribb

Chris Adams wrote:
> 
> The biggest problem is that I can't run anything that uses the
> InstallShield Java Edition.

After I installed the Intel Linux JDK 1.1.5 (v7), the Install Shield stuff in
Together/J (http://www.oi.com) seemed to activate a bug that killed my window
manager (ctwm) and hence shut down my X windows session.  To work around this, I
started a separate X server without a window manager (using the command "X :1")
and ran the Together/J install program on that X server (by setting DISPLAY=:1
in my environment).

Maybe this will help in your situation.




1.1.6 work resumes!

1998-05-11 Thread Steve Byrne

I hate to jinx it by saying anything, but it looks like I have successfully
escaped from the >Gates< of Hell (== I managed to get my data, including the
JDK cvs tree off my "dead" disk and onto a new one).  Thnaks too all
who helped ward off the spells and curses of the evil one in Washington (now
THERE is something to think about!) with their good thoughts and
prayers. :-)

Steve




Linux/Alpha port of JDK

1998-05-11 Thread Chris Adams

Is anyone working on the Linux/Alpha port of the JDK?  I have problems
with the version downloaded from http://www.voicenet.com/~gatgul/JDK/.

The biggest problem is that I can't run anything that uses the
InstallShield Java Edition.
-- 
Chris Adams - [EMAIL PROTECTED]
System Administrator - Renaissance Internet Services
I don't speak for anybody but myself - that's enough trouble.