1.6.3 unable to use system avr-gcc

[dplasa]

I want to use system's installed avr-gcc instead of avr-gcc provided with tarball. I followed http://playground.arduino.cc/learning/linux
and deleted ./arduino-1.6.3/hardware/tools/avr folder.
After that arduino IDE won't start anymore:
arduino-1.6.3$ ./arduino
java.lang.NullPointerException
at processing.app.BaseNoGui.createToolPreferences(BaseNoGui.java:767)
at processing.app.BaseNoGui.initPackages(BaseNoGui.java:606)
at processing.app.Base.(Base.java:256)
at processing.app.Base.guardedMain(Base.java:198)
at processing.app.Base.main(Base.java:113)

[matthijskooijman]

Hm, that's certainly a bug, it shouldn't null pointer out like this.

If you want to use the system avr-gcc, the best to do so is to modify platform.txt, or to add a platform.local.txt alongside it (I added support for this file exactly for this usecase). My platform.local.txt has:

compiler.path=
tools.avrdude.cmd.path=avrdude
tools.avrdude.config.path=/etc/avrdude.conf

Making it use the system avr-gcc. Note that I'm still using a git version from just before 1.6.0, so I'm not entirely sure if this still works exactly like this.

Also, even if this works, the NPE should be fixed as well.

[wayoda]

@matthijskooijman

Hm, that's certainly a bug, it shouldn't null pointer out like this.

You can't just delete important parts of the arduino code and expect the IDE to still work. Not a bug to me and nothing any application can be prepared for.

@dplasa

I want to use system's installed avr-gcc instead of avr-gcc provided with tarball.

The article you link to is 5 years old and this might have been possible a few years ago. Today the arduino code is a fine tuned combinantion of hardware boards and the compilers that are shipped with the IDE.
There is nothing to gain from switching compiler tools etc.

Its not worth the effort going down that path .... sorry

Eberhard

[dplasa]

@wayoda: Well, there are people outside, who still believe in packages, that ship exactly what is new, not just bloated tarballs with just everything kludged together once more again and containing itself even doubles like 'find ./arduino-1.6.3 -name g++ -exec ls -alF {} ;'
-rwxr-xr-x 2 dplasa dplasa 1194972 Mär 30 10:59 ./hardware/tools/avr/bin/avr-g++*
-rwxr-xr-x 2 dplasa dplasa 1194972 Mär 30 10:59 ./hardware/tools/avr/avr/bin/g++*

From that point of view: hell why can't the arduino guys just build proper debian packages. That tarball doesn't look so fine tuned after all.

@matthijskooijman:
Thanks a lot - that did the trick!

[dplasa]

@wayoda:

@matthijskooijman

Hm, that's certainly a bug, it shouldn't null pointer out like this.

If any entry in ./arduino-1.6.3/hardware/arduino/avr/platform.txt is invalid or missing the program just crashes with a NPE. That sure looks like a bug to me.

The least one could expect is a meaningful error message.

[wayoda]

@dplasa

Well, there are people outside, who still believe in packages, that ship exactly what is new,

This is one of the reasons the situtation is just like it is. There where quite a few times in the last years that ubuntu shipped versions of the compiler and/or the uploader tool where behind or beyond the versions required by the arduino libraries or new hardware. The latest and hottest might not always work with the arduino.

Yes, a deb package would be nice but for a cross platform project this is probably a problem with the resources.

[wayoda]

@matthijskooijman

The least one could expect is a meaningful error message.

What would be a meaningful error message if you delete a random entry in the windows registry?

If I ship an application that displays an image on a splash screen and you go out and delete that icon from the application resources folder do you really expect that to be handled with a nice dialog box?

An unrecoverable error occured!

Click <OK> if you think this a good error message!

For the developer the NPE is a very good error message that tell exactly the line of code where the program failed. If this would be caused by a real programming error it would give a good the starting point for a bug hunt.

[matthijskooijman]

@wayoda, I really don't agree there. I think an NPE (just like a segfault) is never acceptable behaviour.

In this particular case, for example something "failed to execute command", "could not find executable", or "invalid platform.txt" might be more appropriate (I haven't looked at this particular NPE to see what is happening exactly).

I'm not saying that things should keep working when a part of the IDE is deleted, I'm just saying that code should be robust and not crash completely when its assumptions about the environment don't hold up.

[dplasa]

@wayoda
From the circumstances of this bug it does seem that the code is not doing any checks when accessing files or directories.

Since the aim of a configuration file (platform.txt) is to make things like compiler location etc. configurable it must handle the case that a config option is invalid or points to a non existing path.

When pointing to an non-existing location (a simple 'stat' call would be sufficient to check that) it should give the user a error message like 'cannot access xyz - check platform.txt' rather than lead to a not initialized object which consequently crashes somewhere later.

At least that's how other, robust sw does that.

[dplasa]

@wayoda

This is one of the reasons the situtation is just like it is. There where quite a few times in the last
years that ubuntu shipped versions of the compiler and/or the uploader tool where behind or
beyond the versions required by the arduino libraries or new hardware.

Isn't that the idea of a package management? To define dependencies? So you could define arduino-1.6.3 depends on avrdude-6.0.1 and avg-gcc-4.8.1.

The latest and hottest might not always work with the arduino.

'might not work' feels like a lame excuse for just making a sloppy tarball, freezing some arduino sw dude's current working directory instead of building a real package.
I never experienced trouble with latest avr-libc, avr-gcc and avr-dude.

[ffissore]

Indeed this is a regression bug. We'll fix it asap