getting wiringpi to work under ubuntu 20.10 on a raspberry pi 4b w/4gb

Over the years, one of the software tools I came to depend on was gpio from the project WiringPi. There were others to be sure, but I like using WiringPi. I came to take it for granted, so much so, that when its author, Gordon Henderson, decided to deprecate WiringPi and stop supporting it, I was more than a bit shocked. I read Gordon’s reasons for exiting, and I agree with his reasons. I’m not here to hash over those reasons as it’s now been over a year since that happened.

In the mean time I installed Ubuntu 20.10 for the Raspberry Pi 4B on my RPi 4B’s and went about the business of making sure the core set of tools that I use on Raspbian were also available on Ubuntu 20.10. As it turns out, WiringPi is available, but it won’t work.

The reason is that the version available via apt is version 2.50. The version at a minimum should be 2.54 or greater, which was a special release that Gordon provided for the 4B right after he officially stopped supporting WiringPi in general.

So I contacted Gordon, who advised me to look on Github for a copy of his code. I found that, cloned it, and tried to build and install it. It built but failed to link due to a symbol defined multiply times error. That was due to a structure definition in a header file that showed up twice in two object files. I fixed that by turning the explicit structure definition into a typedef. When I tried again, it built and linked and deployed the shared library. After that, gpio ran just fine as shown above.

The link to my fork with the one fix is here: https://github.com/wbeebe/WiringPi

I picked up a branch in the fork. I will probably delete that, as all I care about right now is the mainline code. If I do anything it will be to clean up the warnings I see as the code builds (and there are a fair number now) as well as reducing dependence on the pre-processor. Reducing dependency on the pre-processor means replacing #defines with const constants, allowing the compiler to do its job and treat C/C++ as a strongly typed language.

rethinking the use of ubuntu 20.10 on a raspberry pi 4

Yesterday I wrote about how I was staying with Raspbian/Raspberry Pi OS 64-bit because it was, essentially, “smoother” to work with. Then I pulled out my 2GB and 4GB Raspberry Pi 4 little systems and attempted to start an update of the Raspbian OS 32-bit. It’s been a good six months since I worked with those little boxes, and I felt it was time to bring them up to date. I powered up the 4GB system and attempted a standard update (as full root) with apt update && apt upgrade -y. And it failed. For whatever reason apt couldn’t reach the Raspbian servers. After several more attempts and subsequent failures I shut it down. Since I’d already gone to the trouble to populate and initialize another µSDXC card with Ubuntu 20.10, I quickly swapped it onto the 4GB system and powered it back up again. It booted without issue, and to see if I could reach Ubuntu’s update servers, went through the same apt dance. It succeeded, updating Firefox in the process.

I know that getting the software ready for the Raspberry Pi is a huge volunteer effort. I get that, and I certainly appreciate that. But when the servers are unavailable for whatever reason, it tends to cast a pall over the OS. I checked to see if there were any messages about the Raspbian infrastructure being down or just having problems, and found nothing on the usual web sites and forums.

It’s at this point I have to ask myself if I should move on. I left Arch Linux precisely because it would not remain sane if left alone for long periods of time between updates. When my Arch installs essentially committed suicide when attempting an update, I made the decision to move to Raspbian, and never looked back. I might complain about the ages of some of the tools on an Raspbian OS, but I’ll take old and reliably working over new and busted ever single time. Now it’s reliably working Ubuntu updating over hit-or-miss working Raspbian. This is the older 32-bit version, not the 64-bit version that’s still in beta.

One strong point in Ubuntu’s favor is that it’s supported by a business, Canonical, that is totally devoted to OS development and support. The Raspberry Pi Organization is trying to support hardware and the surrounding ecosystem as well as its own OS. Now that Canonical has demonstrated their ability to support the Raspberry Pi, and now that the Pi is using hardware that can in turn support contemporary Ubuntu on ARM64, it might be a good time for the Raspberry Pi Organization to strike a formal deal with Canonical and let Canonical supply the ARM64 OS. This would allow the Raspberry Pi Organization to better concentrate their resources instead of spreading everything and everyone so thin. Ubuntu 20.10 still has some performance issues on the desktop, but at this point I’ll accept that because of the reliability of the operating system and its update servers.

If you think I’m being to harsh with Raspbian, here’s another interesting data point to consider. My most popular blog post for 2020 is “disable chromium update dialog on raspbian buster” ( https://arcanesciencelab.wordpress.com/2020/04/11/disable-chromium-update-dialog-on-raspbian-buster/ ), a problem with Chomium that I wrote about back in April of this year, complete with work arounds.The ultimate fix is to recompile Chromium and rebuild its package, followed by a push out to the update servers. But it would appear that hasn’t happened, not if the continuing interest I keep getting on that article is any indication. And there are other little annoyances that would benefit from a similar refresh as well.

The only problem with switching to Ubuntu is support for older 32-bit hardware. There’s an awful lot of that out in the Real World, embedded in many commercial products as well as personal projects. Those will still need OS support that Ubuntu won’t be able to provide. Perhaps the practical solution is for the Raspberry Pi Organization to hand off 64-bit support to Canonical, while they go back and support just the older 32-bit hardware.

I will admit that my use of this hardware is not quite the norm for others. To me this is a hobby, so I tend to try and keep up with software updates, though not on the absolute bleeding edge. As a hobbyist I can afford to live with the kinks that new features can introduce, as long as I can get some reasonable feature. As of this point in time, I’ve been incentivized as it were to migrate to Ubuntu, at least for the latest Raspberry Pi hardware. Another adventure; we’ll see how that works out for me.