2.0.0 beta 3 Doesn't work on Linux Mint 17.3 mate

The 2.0 beta 3 does not work on Linux Mint 17.3 beta.
First there is something odd aobut the executable in that it cannot be started from caja

When started from the command line, it spits out this:

./arduino-ide

Fontconfig warning: "/etc/fonts/fonts.conf", line 86: unknown element "blank"
Starting backend process. PID: 4232
ATTENTION: default value of option force_s3tc_enable overridden by environment.
/home/bill/Documents/devel/Arduino/ide/arduino-ide_2.0.0-beta.3_Linux_64bit/resources/app/node_modules/bindings/bindings.js:121
        throw e;
        ^

Error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /home/bill/Documents/devel/Arduino/ide/arduino-ide_2.0.0-beta.3_Linux_64bit/resources/app/node_modules/drivelist/build/Release/drivelist.node)
    at process.func [as dlopen] (electron/js2c/asar.js:140:31)
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1034:18)
    at Object.func [as .node] (electron/js2c/asar.js:140:31)
    at Module.load (internal/modules/cjs/loader.js:815:32)
    at Module._load (internal/modules/cjs/loader.js:727:14)
    at Function.Module._load (electron/js2c/asar.js:769:28)
    at Module.require (internal/modules/cjs/loader.js:852:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at bindings (/home/bill/Documents/devel/Arduino/ide/arduino-ide_2.0.0-beta.3_Linux_64bit/resources/app/node_modules/bindings/bindings.js:112:48)
    at Object.<anonymous> (/home/bill/Documents/devel/Arduino/ide/arduino-ide_2.0.0-beta.3_Linux_64bit/resources/app/node_modules/drivelist/js/index.js:25:27)

It does seem to come up and run on Linux Mint 20.1 mate

--- bill

bperrybap:
there is something odd aobut the executable in that it cannot be started from caja

Yeah, unfortunately it's currently required to run it from the terminal. I believe the associated error message is:

There is no application installed for “shared library” files

There is a task in the tracker for adding support for starting the executable by clicking on it in the file manager. Hopefully that will be added in an upcoming release.

bperrybap:

Error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /home/bill/Documents/devel/Arduino/ide/arduino-ide_2.0.0-beta.3_Linux_64bit/resources/app/node_modules/drivelist/build/Release/drivelist.node)

at process.func [as dlopen] (electron/js2c/asar.js:140:31)
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1034:18)
    at Object.func [as .node] (electron/js2c/asar.js:140:31)
    at Module.load (internal/modules/cjs/loader.js:815:32)
    at Module._load (internal/modules/cjs/loader.js:727:14)
    at Function.Module._load (electron/js2c/asar.js:769:28)
    at Module.require (internal/modules/cjs/loader.js:852:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at bindings (/home/bill/Documents/devel/Arduino/ide/arduino-ide_2.0.0-beta.3_Linux_64bit/resources/app/node_modules/bindings/bindings.js:112:48)
    at Object. (/home/bill/Documents/devel/Arduino/ide/arduino-ide_2.0.0-beta.3_Linux_64bit/resources/app/node_modules/drivelist/js/index.js:25:27)

You're welcome to submit a bug report to the issue tracker:

or a pull request to fix this.

I'd guess that supporting outdated OS versions will not be considered a high development priority by Arduino, but perhaps someone from the community will contribute a fix.

This dependency is different than the pre 2.0 IDE as the 1.8.13 works without issue, on older versions of linux.

Dependencies on newer shared libraries than available for an older OS is often not easy to fix.
It can often require that the app be built using special options, on an older OS , or does some static linking, neither of which many developers are too keen to do.

One thing it could do, with a little bit of work, would be fail a bit more gracefully.
Other than that, it should specify which versions of linux it requires.

To fix the click to execute issue, a simple 1 line executable shell wrapper can solve this. (this is what I did on my system)
Ideally, it should be named "arduino" so it has the same name as the wrapper script in all the previous linux releases.
I'm surprised it didn't initially come with it.

--- bill

bperrybap:
This dependency is different than the pre 2.0 IDE as the 1.8.13 works without issue, on older versions of linux.

Arduino IDE 2.0.0 is a complete redo of the Arduino IDE. The entire Java codebase has been discarded. It's now based on GitHub's Electron and the Eclipse Theia IDE framework.

The only thing that was carried over is the arduino-builder code (now integrated into Arduino CLI).

I do like to see care given for older operating systems. I don't know if it's such a factor with Linux, but certainly with macOS and Windows retaining support for older versions allows the IDE to be used on older computers that either are not compatible with newer versions or aren't worth the effort of upgrading. That makes Arduino more accessible to everyone, regardless of economic status, and also fights against the tragedy of perfectly functional computers ending up as e-waste.

But I also understand that in order to move forward sometimes there is no choice but to bump the minimum requirements. In this case, we're also limited by the minimum requirements of the underlying technology. The recent bumps to the minimum macOS and Windows version requirements of the classic Arduino IDE were caused by decisions made by the Golang developers. At least the old IDE versions are still available to those who can't run the latest.

bperrybap:
Other than that, it should specify which versions of linux it requires.

I agree, but considering how many distros there are I don't know how to go about this. Do you have any ideas? I'm guessing it's not so simple as just specifying a kernel version.

bperrybap:
To fix the click to execute issue, a simple 1 line executable shell wrapper can solve this. (this is what I did on my system)
Ideally, it should be named "arduino" so it has the same name as the wrapper script in all the previous linux releases.
I'm surprised it didn't initially come with it.

Thanks for your suggestion. I have added a note about this to the task in the tracker with a link back here.

pert:
I agree, but considering how many distros there are I don't know how to go about this. Do you have any ideas? I'm guessing it's not so simple as just specifying a kernel version.

Yeah, there is lots of "chaos" these days in linux, and app compatibility/incompatibility especially with all the systemd crap that is now impossible to avoid.

I have seen some apps that do try deal with the linux distro (and version) issue.

zoom is a good example.
For linux, they have you pick from 10 versions of linux.
i.e. things like ubuntu, debian, mint, oracle, CentOS, redhat, fedora, openSUSE, Arch, other

Once you select one of those, you get told which version that they support.
Typically it is the active LTS versions.

But even in their case, if you select mint, you are told that it is supported on Mint 17.1+
It is incorrect. With their recent zoom releases, it no longer works on Mint 17 as it depends on some new stuff that is not in mint 17.
I've been trying to get them to update their download page to no longer include Mint 17, but you can't input any bugs/issues unless you are a paying corporate account and the sales guys that I talk to don't understand the issue, even when explained in very simple terms.
They keep wanting to sign me up for zoom how-to classes.

I only run linux but, yeah, it is a mess in linux these days given the mess that linux has become between gome3, systemd, and redhat all creating increasingly incompatible changes between them and each trying to create tricky and sometimes unnecessary dependencies to force users down certain paths (their path).

--- bill

Oh I guess I should mention that snap and flatpak are becoming popular to work around the compatibility issues.
However, I REALLY loath them.
It appears that the 1.8.13 IDE is now available in the Ubuntu store as a snap.

While these bundling technologies can give developers an app package that runs with less effort, both are long term security nightmares as these technologies are in effect fancy new fangled ways to do static linking.
They both suffer the same long term security issues as static linking.

IMO, these technologies,while they do make things easier for developers, they trade one set of problems for another, potentially worse set of problems.

--- bill

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.