March 13, 2026

Build OpenOCD from source

We did all of this, but never ended up using it because the OpenOCD from the Fedora package set suddenly began to "just work".

Version number negligence

I ran into this back in 2023, and now 3 years later, it is still an issue. OpenOCD reports its version number as 0.12.0. It always has and probably always will. In other words the version number is totally meaningless, useless, and entirely worthless.

For all we know, the Fedora package building machinery may be packaging a version of OpenOCD from 1982 and will continue to do so until it detects a version number change.

Building from source

Getting the source is simple enough: 
git clone https://github.com/openocd-org/openocd.git
This article (from April, 2025) suggests building from source and says that it is simple and quick to do so. I do this: 
cd openocd
./bootstrap
It tells me I am missing something called "libtoolize". I get it via: 
su
dnf -y install libtool
Next we try: 
./configure
It complains that it cannot find "jimtcl". 
dnf -y jimtcl-devel
Now ./configure works, but I see these warnings: 
warning: Ignoring macrofiles at /home/tom/.rpmrc:2
configure: WARNING: libusb-1.x not found, trying legacy libusb-0.1 as a fallback; consider installing libusb-1.x instead
There has always been confusion and stupid nonsense regarding libusb. I am just going to ignore this warning. I don't see anything called "libusb-1.x" in the Fedora package set.

At the end of ./configure it spits out a big list of configuration with yes/no status, including: 

ST-Link Programmer                               no
SEGGER J-Link Programmer                         no
Both of which I like to use and have used in the past. We will press on for the time being. 
make
This seemed to go "OK". Before typing "make install", I should use dnf to remove the fedora package.

But I don't. I try running the Fedora package version and now it just works! I wanted to run it to reproduce the error I was getting and document the issue, but that is no longer relevant. At least not for now.

As always, I expect any mysterious problem that "fixes itself" to crop up again at some unpredictable future time, no doubt when it will cause the most trouble.

Build the Raspberry Pi fork

Fedora OpenOCD almost works, but there are problems with the RP2040.
We do this 3-16-2026 
cd /Projects/OpenOCD
git clone https://github.com/raspberrypi/openocd.git
mv openocd rpi
cd rpi
./bootstrap
./configure --enable-picoprobe
make -j4
At this point we could "su ; make install" -- and maybe we should, but in any case we should uninstall the Fedora openocd first. I do this: 
su
dnf remove openocd
dnf -y install capstone
make install
I don't know what capstone is, but the Fedora openocd required it and maybe the raspberry pi fork does also.

Try the build again

Testing (trying to use) this build of OpenOCD does not work (for the rp2040). I repeat the build, using this: 
./configure --enable-hambone
It accepts this as well as it did --enable-picoprobe. Apparently "picoprobe" is not a supported adapter -- nor is "hambone".
I try this: 
./configure --enable-cmsis-dap
And this gives the error: 
configure: error: hidapi is required for adapter "CMSIS-DAP v1 compliant dongle (HID)".

Dig deeper

Searching online reveals many recipes for this build, and none of them seem to match the current situation. And there is no documentation. I see this: 
cd /Projects/OpenOCD/rpi
git branch
* rpi-common

git branch -a
* rpi-common
  remotes/origin/HEAD -> origin/rpi-common
  remotes/origin/libgpiodv2
  remotes/origin/lurch-patch-1
  remotes/origin/master
  remotes/origin/master+rp2040
  remotes/origin/master+swd+rp2040+picoprobe
  remotes/origin/master+swdetc
  remotes/origin/picoprobe
  remotes/origin/picoprobe_tmp
  remotes/origin/rp2040-0.12-rc2
  remotes/origin/rp2040-master
  remotes/origin/rp2040-v0.11.0-test
  remotes/origin/rp2040-v0.12.0
  remotes/origin/rpi-common
  remotes/origin/sdk-2.0.0
  remotes/origin/tcl-core0-default
  remotes/origin/upstream-v0.12.0-master
So, I have many choices. I try this: 
git switch picoprobe
branch 'picoprobe' set up to track 'origin/picoprobe'.
Switched to a new branch 'picoprobe'
make clean
./bootstrap
./configure --enable-picoprobe
This fails as follows: 
configure: WARNING: libusb-1.x not found, trying legacy libusb-0.1 as a fallback; consider installing libusb-1.x instead
checking for libusb... no
configure: error: libusb-1.x is required for the Raspberry Pi Pico Probe
So, on one hand it says it will try libusb-0.1 as a fallback, but later insists that I must have libusb-1.x -- I try this: 
dnf install libusb1-devel
This fixes the problem and here is part of the summary when it finishes: 
Raspberry Pi Pico Probe                 yes
ST-Link Programmer                      yes (auto)
Versaloon-Link JTAG Programmer          yes (auto)
CMSIS-DAP v2 Compliant Debugger         yes (auto)
CMSIS-DAP Compliant Debugger            no
Asking for cmsis-dap gives me the complain about "hidapi", but I do have the v2 flavor (if I care) and maybe that will do if I need it.

The compile gets errors: 

src/jtag/drivers/ulink.c:1491:50: error: 'calloc' sizes specified with 'sizeof' in the earlier argument
  and not in the later argument [-Werror=calloc-transposed-args]
 1491 |                 tdo_buffer_start = calloc(sizeof(uint8_t), scan_size_bytes);
I try this: 
./configure --enable-picoprobe --disable-ulink
make
And now I get this error: 
src/flash/nor/ambiqmicro.c:152:41: error: 'calloc' sizes specified with 'sizeof' in the earlier argument
  and not in the later argument [-Werror=calloc-transposed-args]
  152 |         ambiqmicro_info = calloc(sizeof(struct ambiqmicro_flash_bank), 1);
The same error in a different file. It is strange that a compiler error regarding calloc() calls is triggering in both cases.

Game over, insert coin

This tangled mess is way, way more that I want to deal with. Somebody else needs to fix this disaster. I have other things to do.

Have any comments? Questions? Drop me a line!

Tom's software pages / tom@mmto.org