Problem on CentOS 7 - too old libstdc++ for canvas

[padys]

Dependency on canvas could generate problems on older systems (in my case CentOS 7). The newest version - canvas@2.7.0 - requires newer libstdc++ library absent in CentOS 7.

See my comment at: https://github.com/Automattic/node-canvas/issues/1753#issuecomment-796494143

[SeanSobey]

Unfortunately, canvas is quite a coupled dependency to this library, so any version updates I do are always done carefully but also look to take advantage of improvements done in canvas and the build pipeline, eg with node-gyp and prebuilt binaries, which are always causing issues.

Supporting multiple versions of canvas would be quite a lot more overhead, but not impossible I think. The best suggestion I have would be to fix your version of this lib at your highest supported version of the canvas upstream dependencies you require. 2.4.1 uses canvas 2.6.1 which should work for you?

[padys]

I'm not familiar how your library is coupled with canvas, which new features do you use. Maybe a good solution is to include canvas as peer-dependency? In this case the main application would be responsible for loading canvas in any version in range as you specify, which is also compatible with operating system.

[padys]

Your library in version 2.4.1 in dependency list has canvas "^2.6.1". The sign "^" means any newer release in major version "2.x.x". Therefore it loads also canvas "2.7.0".

[SeanSobey]

Canvas has for a while been in the process of moving to prebuilt binaries from the much more dependency-heavy and error-prone node-gyp approach. But platform support is slow in coming so I bump the dependency as more are available. This is the main reason for increasing the version.

A recent canvas version made working with fonts and SVG easier, this was included in the recent 3.x.x migration IIRC.

I did consider making it a peer dependency but the aforementioned binary availability across platforms would have made installs a nightmare. There are a few other canvas-binary related issues raised here but frankly I am surprised there are not more. Once canvas has stabilized the binary delivery system I will relook at this.

Your library in version 2.4.1 in dependency list has canvas "^2.6.1". The sign "^" means any newer release in major version "2.x.x". Therefore it loads also canvas "2.7.0".

Ah ok, I see. I should have fixed the version, I will do so after having a look at what canvas has done for this 2.7.0 update, but this may or may not help your issue immediately.

Maybe fixing the version in npm package-lock.json could work in the meantime?

[padys]

File package-lock.json is autogenerated and rather shouldn't be modified by hand. Even if you modify package-lock.json in '2.4.1', the problem will still remain in newer packages. Other disadvantage is necessity of republishing '2.4.1' on NPM. I think it's not a right way.

[howlettga]

Thanks for explaining the issue! I just spent 2 days trying to debug installing canvas on CentOS 7 without realizing it was an issue specific to version 2.7.0. Anyways, since this is the case, it's a rather simple solution that shouldn't require any fix in chartjs-node-canvas. Just declare a compatible version of canvas in the package.json and npm will pick up the existing dependency as the one to use for chartjs-node-canvas. Here is my package.json:

  "dependencies": {
    "canvas": "2.6.1",
    "chart.js": "^2.9.4",
    "chartjs-node-canvas": "^3.1.0"
  },

No need to mess with package-lock, although you probably will need to clear your node_modules folder

I think this should really be an issue created in the node-canvas repo and not the chartjs-node-canvas repo.