There are sure to be bugs.  The goal is to make the install as painless
as possible.  Send back comments if something could be easier.

If your not able to open the port (read the errors carefully) then you may
not have permission to use the device.  Redhat linux ships with the following
permissions:

crw-r--r--   /dev/ttyS?

Users need to be able to read and write with serial communication...

chmod 666 /dev/ttyS? 

should fix the problem.

If you run into a problem building the rxtx package please report the following
with the bug report.

   was java in your PATH when you tried ./configure.  'which java'
      JDK_HOME is checked also...
   which machine type are you running on?  'uname -a'
   which jdk version.
       Linux users:  If your trying to use event notification, make sure
       your using the native thread package and linux-2.2 kernel.
   which rxtx version.
   what version of libc are you using
   what cc are you using
   which version of commapi you have.

If your having problems with JCL make sure you have read through CommAPI.

with autoconfig/make/libtool/... problems report the following  if they are
not present please install them.

   autoconf --version
   automake --version
   libtool --version
   make --version

Here's whats on my system for comparison.  Correct versions are important.

   autoconf 2.13
   automake 1.4
   libtool 1.2b
   make 3.76.1

Unterminated sed command errors usually result from `find` producing unexpected 
results.   If you are unsure remove all comm.jar and javax.comm.properties files
and use configure to place them in the correct place. 


mail any bugs to trentjarvi@yahoo.com.  

jdk-1.2 users may not on redhat systems that java complains about not being
able to find libstdc++-libc6.0-1.so.2.  A symbolic link can be used to get
around this feature of java.

 /usr/lib/libstdc++-libc6.0-1.so.2 -> libstdc++.so.2.8.0

Known 'Features'.


1.  There is no parallel support in rxtx.  Good project for a interested 
    programmer.  It should not be too hard.  Some initial support has been
    added

2.  This release has only been tested on linux.

3.  The library does not handle SIGINT and clean up.

4.  Flow control with small FIFO's on the other side.   See the setserial 
    manpage for how to change the uart setting mentioned.

   Chris Kakris writes:

   I don't know if you would call it a bug or not.  I believe
   (talking to a hardware engineer here) that today all modern
   devices like modems and printers have large buffers.  When the
   device requests hardware flow control it may actually take a
   while for the server to stop sending data but that's ok
   because the device has enough of a buffer to accept the
   incoming data.  I guess this happens because the server has
   been filling its own buffer and must empty it.  In our
   situation we can't afford to do that - the server must stop
   immediately.

   I am guessing that this may be a kernel buffering issue.
   When we set the UART to a 16550 type then I suspect
   that the kernel doesn't create a buffer at all so when it does
   see the flow control (raised or lowered) it is able to comply
   without freaking out that it has a buffer that it needs to
   emptied.

5.  BlackBox has a hard coded limit in BlackBox.java that prevents it from 
    running if you dont specify a port.  We are considering alternative ways
    of handling the large number of port names in unix.  The line in question
    is:

	 portDisp = new SerialPortDisplay[50];


Older Linux Systems (libc5) should upgrade to a glibc system with libpthread-0.7 or newer.  We have run into many problems with older libraries.  SIGSEGV was the most common symptom.  Reported by  Peter Bennett <bencom@bencom.co.nz>
