Don't include RXTX in the Linux distribution.

[GoogleCodeExporter]

The dependencies of the software (rxtx, antlr, others?) shouldn't be
packaged with the software but called out in the installation instructions.
 This makes it easier for package managers to install it system-wide and
deploy on different architectures.

Original issue reported on code.google.com by nixpho...@gmail.com on 18 Apr 2009 at 5:04

[GoogleCodeExporter]

Good idea.  Is RXTX available as a package on most Linux distributions?  Should 
I include neither the .jar nor the 
native library with the Arduino distribution?

Original comment by dmel...@gmail.com on 21 May 2009 at 8:57

• Added labels: OpSys-Linux

[GoogleCodeExporter]

Yes, I think *not* including both the .jar and native library are good ideas, 
as it
seems that it's provided by librxtx.  As for which distros ship it, I know 
Gentoo
does and it looks like Ubuntu (https://launchpad.net/ubuntu/+search?text=rxtx),
Debian (http://packages.debian.org/lenny/librxtx-java), and Fedora
(https://admin.fedoraproject.org/pkgdb/packages/name/rxtx) do too.

Original comment by nixpho...@gmail.com on 22 May 2009 at 1:43

[GoogleCodeExporter]

I did some more research and we may need to include RXTX for now.  On Ubuntu, 
the 
RXTX package doesn't install in a way that's visible to the Sun JRE, requiring 
manual
configuration (or for me to guess where it will be on each distribution):
https://bugs.launchpad.net/ubuntu/+source/rxtx/+bug/380027

Also, the current RXTX package doesn't work on 64-bit versions of Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/rxtx/+bug/361635

Once Ubuntu has an RXTX package that works without configuration on both 32-bit 
and
64-bit installs, then we should probably remove it from the Arduino 
distribution.

Original comment by dmel...@gmail.com on 24 May 2009 at 6:52

[GoogleCodeExporter]

Original comment by dmel...@gmail.com on 15 Jun 2009 at 7:52

• Changed title: Don't include RXTX in the Linux distribution.
• Changed state: Accepted

[GoogleCodeExporter]

It is a good idea because each distribution SHOULD compile rxtx with specific 
options
like the place of /var/lock files. But In my case, I tried the one provided by
Mandriva and it didn't work with Arduino ide. Finally, I created a packet for
Mandriva and included a new version of rxtx that solves all issues. (
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1259672641/2 )

Original comment by alejandr...@gmail.com on 9 Dec 2009 at 8:42

[GoogleCodeExporter]

Following on from the discussion in 
http://code.google.com/p/arduino/issues/detail?id=193, change 
http://github.com/arduino/Arduino/pull/5 overrides the serial devices used by 
rxtx without having to provide a patched version.

Original comment by p.d.oli...@gmail.com on 7 Oct 2010 at 6:06

[GoogleCodeExporter]

Issue 385 has been merged into this issue.

Original comment by dmel...@gmail.com on 27 Nov 2010 at 11:00

[GoogleCodeExporter]

p.d.oliver: I'd rather not implement the serial port scanning within the 
Arduino IDE code.  This seems like something RXTX should do.  Anyone know how 
to request the addition of /dev/ttyACM* to the devices scanned by the version 
of RXTX packaged with Debian and Ubuntu?  Alternatively, maintainers of the 
Arduino packages for these distributions could apply your patch as part of the 
packaging process.  

Original comment by dmel...@gmail.com on 27 Nov 2010 at 11:19

[GoogleCodeExporter]

The advantage of doing it Arduino is that you don't have to rely on a special 
version of RXTX being present. If upstream RXTX was modified to allow you to 
pass it at runtime a list of ports to scan, that may be the best solution.

Debian already includes a patch to make RXTX scan a greater range of ports: 
http://git.debian.org/?p=pkg-java/rxtx.git;a=commit;h=3302001ca24b671e75d43c9feb
d771e709a759e7

However, a comment in the RXTX source code warns:

> You may add additional ports
> here but be warned that too many will significantly
> slow down port enumeration.  Linux 2.6 has udev
> support which should be faster as only ports the
> kernel finds should be exposed in /dev

Perhaps this kind of slowness is no-longer an issue, at least not for the users 
targeted by these distributions?  I shall ask on the RXTX mailing list to find 
their view.

Original comment by p.d.oli...@gmail.com on 28 Nov 2010 at 1:56

[GoogleCodeExporter]

> Also, the current RXTX package doesn't work on 64-bit versions of Ubuntu
It looks like the included version isn't working on 64-bit either, as of the 
0021 release and all the way up to git 4d3b26. I'm seeing this error:
     [exec] java.lang.UnsatisfiedLinkError: /home/cci/projects/dbarnett_Arduino/build/linux/work/lib/librxtxSerial.so: /home/cci/projects/dbarnett_Arduino/build/linux/work/lib/librxtxSerial.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver

I deleted build/linux/dist/lib/librxtxSerial.so and everything loaded with just 
this warning:
     [exec] WARNING:  RXTX Version mismatch
     [exec]     Jar version = RXTX-2.1-7
     [exec]     native lib Version = RXTX-2.2pre2

Original comment by daviebd...@gmail.com on 3 Dec 2010 at 9:47

[GoogleCodeExporter]

That's when I download the source from github and do "ant && ant run", btw.

Original comment by daviebd...@gmail.com on 3 Dec 2010 at 9:49

[GoogleCodeExporter]

I'm starting to change my philosophy on this one.  I feel like the Arduino 
software download on the Arduino site should be something like a fully 
self-contained archive with appropriate versions of all dependent software.  
That way, we know it works consistently with what we expect.  Alternatively, 
people can package Arduino for their Linux distribution in a way that uses the 
distribution's packages for other software (like RXTX).  In that process, they 
can also ensure that Arduino works properly with those versions of that other 
software.  But it's difficult for us to make the Arduino software work well 
with any arbitrary version of a dependencies that might be on someone's 
distribution.  For example, lots of avr-gcc versions have various problems with 
different aspects of the Arduino core, which might be avoided if we shipping 
the toolchain in the Linux software download. 

Thoughts welcome.

Original comment by dmel...@gmail.com on 23 Feb 2011 at 4:21

• Changed state: New

[GoogleCodeExporter]

By bundling these libraries with Arduino you're either committing yourself to 
maintain them indefinitely, or accepting that you will always carry out of date 
versions.  Neither sounds ideal to me, but I can see how it would seem better 
than the alternative, especially since you already have to do this on Windows.

Note, however, that this won't solve all of your compatibility problems.  For 
example, RXTX compiled on Ubuntu will not work on Fedora without providing 
fiddly installation instructions, because the lock file directories have 
different permissions.  Expect to see similar issues crop up in the future.

If Linux distributions are expected to get things working with unbundled 
libraries, wouldn't it be better to have this work take place once in the 
Arduino project, rather than independently in each distribution?  Get patches 
upstream so you don't have to worry about them any more, rather than 
maintaining your own fork.  The target audience for the bundle is presumably 
those wanting the latest and greatest Arduino before it's included in their 
Linux distribution, so perhaps you could always bundle the latest version on 
any libraries, too, and trust that distributions will catch up when they're 
ready.

Original comment by p.d.oli...@gmail.com on 23 Feb 2011 at 3:56

[GoogleCodeExporter]

Thanks for the feedback.  I basically agree with what you said.  I think the 
best approach is probably to avoid patching dependencies whenever possible, but 
still provide a download that includes them.  That way, people can get a known 
good version (although, as you point out, one not necessarily fully compatible 
with their distribution) or can fallback on the distribution's version if they 
prefer.  In some cases, though, this may not be possible, as patching 
dependencies might be the only way to achieve some feature.  

In any case, I'll try to take a closer look at doing the serial port scanning 
in Arduino.

Original comment by dmel...@gmail.com on 24 Feb 2011 at 2:47

[GoogleCodeExporter]

The 64bit rxtx shipped with Arduino doesn't work on openSUSE 11.1 or 11.4, so 
the only use in shipping it is to provide a starting point for a filename to 
search for in the distribution's package repository.

The version shipped with 0021 however works fine, so I just copied that to 
0022. I think the distribution's version worked too.

The IDE's serial port scanning is practically useless withudev for a properly 
set up system, which uses udev rules to create symlinks of choice hat point 
always to the /dev/ttyUSBX belonging to a particular hardware device. Because 
the drop-down list is populated to narrow rules and no extras can be entered 
manually, the fixed-name symlinks are inaccessible from the Arduino IDE.

At the very minimum the IDE should scan for and offer all devices that match 
/dev/ttyUSB*, then one can choose symlinks like /dev/ttyUSB_myarduinomega and 
not have to work out which of the ttyUSBX one has to use.

Original comment by gooc...@top.geek.nz on 30 Oct 2011 at 8:35

[GoogleCodeExporter]

librxtxSerial.so of 0023 and 1.0, used on openSUSE 11.4 (I don't know what the 
librxtxSerial64.so is for), doesn't work. Replacing it with the same file from 
0021 works fine. 

Original comment by gooc...@top.geek.nz on 14 Jan 2012 at 11:51

[GoogleCodeExporter]

Hi umm, yeah, regarding the whole 
who-is-going-to-fix-the-whole-librxtx-with-UNO-et-al business. This nonsense 
has got to stop! More than a year ^H^H^H^H two years now and still nobody has 
taken ownership of it. Users don't care about your preferences for what you 
think is properly done nor where, because, what's even more improper is that 
this problem has persisted for so long with no resolution. At the very least 
the IDE/GUI should warn users of the problem and direct them to THE solution. 
You are spending goodwill/karma/whatever for naught by allowing this to 
persist. 

Original comment by electrod...@gmail.com on 1 Feb 2012 at 10:20