This issue from 2015 was the only remotely relevant info I could find; an exact search for the error message (error: call of overloaded ‘New(long unsigned int&)’ is ambiguous) yields zero matches, which is always a bad sign in my experience. I will add my details to it.
I meant Install problem · Issue #3 · monarco/node-red-contrib-monarco-hat · GitHub
Also, did you install prerequisites?
1 Like
Ah! I had not come across that one - it is indeed the exact same error. Good. I will add to that issue. TBF, I have to say Monarco's support has been truly outstanding; they have helped resolve multiple issues in the four or five years I've been using their product and usually respond to my emails within 24 hours - and they come back to me to ask how I'm getting on when I've failed to respond. I honestly can't think of any company I've dealt with that comes even close to this level of support. That said; I never thought this was an issue that had anything to do with them; the error is quite clearly coming from the spi-device module which has nothing to do with Monarco - it's just a dependency.
At first I was going to be quite rude responding to this, but you know what, let me take another look. I know I did check the readme before even trying to install it the first time, but maybe I missed something.
Edit: Nah, it's just build-essentials, which was already present by default. It's not easy to know of course, but I do try to help myself before asking others. It's often quicker - and certainly less aggravating.
I seen your initial response. It wasn't that rude ;). The only thing I would say in defence is we don't know what you have/haven't done and if we don't ask, it may well turn out to be the answer. Let's just say this, if you did read the readme, you are in the minority 
I'm not 100% certain that is true.
Is there any harm in running the requested prereq commands then trying again?
Well, it felt unnecessarily sharp, considering you're only trying to help. But I too often find myself in this situation when I turn to the community for help: the conversation goes off the rails and starts being about completely unrelated (or only tangentially related) issues. Typically it's "why are you even trying to do this when X works fine?" - or it is "I'm going to assume you have no idea what you're doing based only on the fact that I don't know who you are"
Do you mean this?
If so, this has nothing to do with the Monarco hat; it's just a convenience bash script for installing/updating Node-RED (and Node.js) itself - and yes, I have read through all of it before determining I could just as well do those things manually. There are reasons why I decided to not to use that script to install Node-RED, but they lie wholly outside this conversation.
The build essentials part yes.
No. Build essentials installs the GNU compiler collection, GNU debugger, and other development libraries and tools required for compiling software
And since the issue you are seeing is a compilation issue, it was (imho) not a terrible idea to run it again.
Not really. Just trying to help
So, 5m digging...
I see this package depends on Monarco which has a dependency on spi-device v2 which is well out of date (current version of spi is v3.1.2) which leads to this post: node-gyp fails on armv7 32bit · Issue #21 · fivdi/spi-device · GitHub. If you read that thread it starts off with the same problem & ends with "This issue has been fixed and the fix is available with spi-device@3.1.2 which has been published on npm"
In short, this package and it's Monarco dependency need updating to use the latest version of spi-device.
2 Likes
Now we're talking.
Edit: I've added your find to the GitHub issue and will fork and see if I can get it to work with an up to date version of spi-device - if so I'll send them a PR. Thanks!
1 Like
$ npm i https://github.com/clickworkorange/node-red-contrib-monarco-hat.git
added 3 packages, and audited 444 packages in 1m
67 packages are looking for funding
run `npm fund` for details
found 0 vulnerabilities
Edit: To clarify, the spi-device dependency is not in node-red-contrib-monarco-hat but in monarco-hat-driver-nodejs, upon which it depends. My fork of node-red-contrib-monarco-hat depends on my fork of monarco-hat-driver-nodejs, which depends on spi-device 3.1.2, and as can be seen above this installs without issue. Phew.
The only problem I have now, is that the one Monarco-Hat I have is installed on the Pi I'm actually using, and if I decommission that a lot of stuff will stop working around here - some of which I need to work at all times. Not sure how I can test the change. But I'll send a PR and see if Monarco can help with that. Looking at the spi-device history I reckon it'll be just fine.
You could do it on a single device as well of course since there are no real issues running multiple instance of nr other than available ports and memory.
Can you do some testing "out-of-hours"? when it isn't being used?
If not, you need to give that some thought anyway if this is a mission critical system.
I could, but since I also decided to jump to bleeding edge Devuan Daedalus (which hasn't even got a release date yet), and switch from a Pi2 1.1 to Pi2 1.2, and switch from a 32 to 64 bit kernel while I was at it, starting from scratch on a second system was the only option. Why do this? In short: because I am lazy - going bleeding edge now will save me having to switch release for a while (several years, I hope), while ensuring I get the maximum time out of security updates (this system runs with unattended-upgrades). If I'm going to spend time upgrading I might as well upgrade as far as possible.
I try to avoid "mission critical" as far as possible; the automation is only a layer on top of things that already work. That said, I do like to minimise downtime of this computer as far as practical. My plan is to get to a point with the Pi2 1.2 where I feel there's a good chance I can fix any remaining issues within a day or two of making the swap.
I ran into one problem today, that I'm unsure how to deal with: owfs is missing from the Debian Bookworm / Devuan Daedalus repos - probably because of some yet to be resolved bug that has been found (I think it was pulled in January). If I build from source, I'll have to install a load of build requirements (this is for aarch64, and I have no other such system to hand), and more importantly, I lose unattended-upgrades for it. I think I'll have to though, and just try to remember to switch to the repo version once it's published...
# apt-get install owserver
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package owserver
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
