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

[ffissore]

Hourly build will soon contain a mitigation to this issue. It doesn't NPE but it's still impossible to use system toolchain. This is due to the fact that compiler.path is {runtime.tools.avr-gcc.path}/bin/ or, generalized, {SOMETHING UNDEFINED}/something hardcoded
A fix should look for non replaced placeholders and remove them

[wayoda]

What about a a comment in the systems platform.txt, boards.txt, programmers.txt

# DO NOT EDIT -- see https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5---3rd-party-Hardware-specification

[matthijskooijman]

Hourly build will soon contain a mitigation to this issue. It doesn't NPE but it's still impossible to use system toolchain. This is due to the fact that compiler.path is {runtime.tools.avr-gcc.path}/bin/ or, generalized, {SOMETHING UNDEFINED}/something hardcoded
A fix should look for non replaced placeholders and remove them

The fix you suggest would not work, since it would end up with "bin/avr-gcc", which is not a valid path to the system gcc.

We previously discussed this issue and decided that using a platform.local.txt file is the way to go for using the system toolchain (and apparently that still works). I looked up the discussion, I think this is a good place to start in the thread: https://groups.google.com/a/arduino.cc/d/msg/developers/4jL4nL_YJ1k/E-AW4XFD-W0J

As noted in the above post, just messing with the executable path, as you're now suggesting, is not sufficient, because of the avrdude -C option, which points to its config file (and must change from a file in the bundled toolchain dir to /etc/. OTOH, it now seems that the avrdude path is built from the runtime.avrdude.path option, so if that's empty, the avrude.conf will end up as /etc/avrdude.conf as expected, so things are a bit different from when that post was made, I guess.

[ShorTie8]

@wayoda
"There is nothing to gain from switching compiler tools etc."
I beg to differ with about this.
How about getting the IDE to work on platforms you do not support ??
Namely ARM.
With the addition of the platform.rewrite in 1.6.3 and the GPG signature checks in 1.6.4,
it seems you guys are getting awful picky .. :(~

ShorTie

[wayoda]

@ShorTie8
The original posting was about editing internal config files of the arduino distribution, which broke the whole package.

Support for what you would like to do:

How about getting the IDE to work on platforms you do not support ?? Namely ARM.

is available for a couple of years now: https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5---3rd-party-Hardware-specification

With the addition of the platform.rewrite in 1.6.3 and the GPG signature checks in 1.6.4,
it seems you guys are getting awful picky .. :(~

What I wrote is my personal opinion, I am not part of the developers team.

[ShorTie8]

Sorry, But
@dplasa "I want to use system's installed avr-gcc instead of avr-gcc provided with tarball."
is exactly what I'm talking about to.
The IDE does not support ARM, so you need to use all of the systems stuff because they offer no precompiled packages for it. So the couple of years thing does not hold true, imho.

Oh well, Once again Sorry, and sorry for even saying anything.

Have A Great Day
ShorTie

[ffissore]

Fixed. Fix will be available in next hourly build http://www.arduino.cc/en/Main/Software#hourly