openocd: error while loading shared libraries: libhidapi-hidraw.so.0 (missing dependent libraries for binary blobs)

[dwrobel]

Basic setup as described here: https://github.com/earlephilhower/arduino-pico/issues/1695

I just changed in Arduino V2 -> Tools - > Upload Method: from Default UF2 to "Picoprobe (CMSIS-DAB)".

An attempt to upload a sketch generates:

/home/dw/Arduino/hardware/pico/rp2040/system/openocd/bin/openocd: error while loading shared libraries: libhidapi-hidraw.so.0: cannot open shared object file: No such file or directory
Failed uploading: uploading error: exit status 127

I have all of those libraries installed on the system:

$ ldd /home/dw/Arduino/hardware/pico/rp2040/system/openocd/bin/openocd
    linux-vdso.so.1 (0x00007ffd9031e000)
    libusb-1.0.so.0 => /lib64/libusb-1.0.so.0 (0x00007fe3488f9000)
    libhidapi-hidraw.so.0 => /lib64/libhidapi-hidraw.so.0 (0x00007fe3488f1000)
    libutil.so.1 => /lib64/libutil.so.1 (0x00007fe3488ec000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007fe3488e7000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fe348022000)
    libudev.so.1 => /lib64/libudev.so.1 (0x00007fe3488b3000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fe348955000)
    libcap.so.2 => /lib64/libcap.so.2 (0x00007fe3488a7000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fe348883000)

but as mentioned here in flatpak none of them are accessible.

If dynamically linked binaries are being used by arduino-pico then you should also consider providing missing dependent libraries. Even running natively (without flatpak) there is no guarantee that all of the libraries particular tool was compiled against will be still available locally.

In order to make it working on flatpak I simply renamed openocd to openocd.bin then created a new openocd script with the following content:

$ cat openocd 
#!/bin/sh
LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:~/Arduino/hardware/pico/rp2040/system/openocd/bin/../lib exec ~/Arduino/hardware/pico/rp2040/system/openocd/bin/openocd.bin "$@"

and added missing libraries to ~/Arduino/hardware/pico/rp2040/system/openocd/lib directory and it started to works fine:

"/home/dw/Arduino/hardware/pico/rp2040/system/openocd/bin/openocd" -f "interface/cmsis-dap.cfg" -f "target/rp2040.cfg" -s "/home/dw/Arduino/hardware/pico/rp2040/system/openocd/share/openocd/scripts" -c "adapter speed 5000" -c "program {/home/dw/.var/app/cc.arduino.IDE2/cache/arduino/sketches/BA1CFB3C333AF819B31175B2A774E3BF/Temperature.ino.elf} verify" -c "reset init" -c "resume" -c "exit"
Open On-Chip Debugger 0.12.0-g4d87f6dca (2023-08-24-21:19)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
Info : Hardware thread awareness created
Info : Hardware thread awareness created
adapter speed: 5000 kHz

Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6605481DB8F9B34
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 5000 kHz
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x10000001
Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints
Info : [rp2040.core1] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core1] target has 4 breakpoints, 2 watchpoints
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections
[rp2040.core0] halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
[rp2040.core1] halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
** Programming Started **
Info : Found flash device 'win w25q16jv' (ID 0x001540ef)
Info : RP2040 B0 Flash Probe: 2097152 bytes @0x10000000, in 32 sectors

Info : Padding image section 1 at 0x10011270 with 144 bytes (bank write end alignment)
Warn : Adding extra erase range, 0x10011300 .. 0x1001ffff
** Programming Finished **
** Verify Started **
** Verified OK **
[rp2040.core0] halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
[rp2040.core1] halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00

[earlephilhower]

Distributing copies of system shared libraries really feels like reinventing DLL Hell but under Linux and is not something I'd consider just to make Flatpacks work.

Every distro (and CPU architecture) is going to have their own versions of these SOs, and when they're kept in the system paths then the security updates and bug fixes "just work" without me needing to track and release new toolchains every time a shared library updates.

Sorry, I know you like Flatpacks, but running this core from inside one is really not recommended because of all the limitations you keep coming up against.

[dwrobel]

Every distro (and CPU architecture) is going to have their own versions of these SOs

And that's the problem. When my system will switch to a newer version (e.g. from .so.0 to .so.1 ) of one of the dependent libraries then (e.g. ~/Arduino/hardware/pico/rp2040/system/openocd/bin/openocd) will simply stop working. Because instead of entirely relying on the system binaries and shared libraries you've decided to provide only binary blobs but without dependencies. Unfortunately this is entirely broken idea.

Please decide either to use system binaries and dependent libraries or stop shipping binaries if you don't care about their dependencies.