moving back to raspbian 64 bit, dropping work on wiringpi

Moving Back to Raspbian 64 bit

On several occasions I’ve written about moving from Raspbian Buster 64 bit to Ubuntu 20.10. I was never completely comfortable with using Ubuntu 20.10 on a Raspberry Pi 4B, not even the version with 8GiB of RAM. But I stuck with it because I thought it would reward my usage over time, with fixes and updates. That all disappeared when I tried to run my physical computing tools under Ubuntu.

I wrote all my tools with Google’s Go and GoBot ( https://github.com/hybridgroup/gobot/ ). I don’t remember what version of Go I started with, but my tools build and work with the latest version of Go, 1.15.3. Or they do under Raspbian. When I set up my build environment under Ubuntu and attempted to run my tools, nothing worked.  When I set up the same under Raspbian Buster 64 bit, they all worked just fine. The key to understanding how my tools work is that they drive everything on the Raspberry Pi’s I2C bus. For an example look at https://arcanesciencelab.wordpress.com/2018/06/24/golang-on-the-raspberry-pi-part-4/ . The GPIO pin functionality may still work, but for me I’ve got shift registers and intelligent peripherals on I2C, and I need it to work. It doesn’t under Ubuntu 20.10, but it does under Raspbian Buster 64 bit.

At this point I’m back on Raspbian, and will stay there for the foreseeable future.

Leaving WiringPi

I’m going to stop working with WiringPi. Gordon Henderson stopped working on it in August 2019. I managed to fork a copy here ( https://github.com/wbeebe/WiringPi ) from a group that made a copy of the code and then started their own work on it. I fixed a minor coding problem that kept the shared library from linking under Ubuntu. It seemed to work (gpio readall), what with the very little testing I did. After spending about a week of evenings just looking at how the code is written and organized, I’ve decided to leave well enough alone. For physical computing I have my Golang work, and there are other tools, especially in Rust, that I can turn to if I need them.

I’m back to a general state of calm and comfort with Raspbian 64 bit and Golang. I’ll just take that and move along.

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.