`OPENOCD_SCRIPTS` path wrong; missing libs

[cyber-murmel]

The FHS wrapper for OpenOCD seems to add openocd-esp32 to the OPENOCD_SCRIPTS variable. This seems to be a result of the tools.json

Versions

nixpkgs_rev = "1f7e3343e3de9e8d05d8316262a95409a390c83b";  # master on 2024-03-20
nixpkgs-esp-dev_rev = "e12a865871e084996defa091a5660537a9b086fb"; # master on 2024-03-20

Package Installed

esp-idf-esp32c6

Observed Behavior

$ which openocd
/nix/store/mg9zsdw37qh07sz35kc1jxd886hdj88a-openocd-esp32-esp-idf-v5.1.2/bin/openocd

$ openocd
/nix/store/mg9zsdw37qh07sz35kc1jxd886hdj88a-openocd-esp32-esp-idf-v5.1.2/bin/openocd: line 3: /nix/store/mg9zsdw37qh07sz35kc1jxd886hdj88a-openocd-esp32-esp-idf-v5.1.2/bin/.openocd-wrapped: cannot execute: required file not found

$ cat /nix/store/mg9zsdw37qh07sz35kc1jxd886hdj88a-openocd-esp32-esp-idf-v5.1.2/bin/openocd
#! /nix/store/4vzal97iq3dmrgycj8r0gflrh51p8w1s-bash-5.2p26/bin/bash -e
export OPENOCD_SCRIPTS='/nix/store/mg9zsdw37qh07sz35kc1jxd886hdj88a-openocd-esp32-esp-idf-v5.1.2/openocd-esp32/share/openocd/scripts'
exec -a "$0" "/nix/store/mg9zsdw37qh07sz35kc1jxd886hdj88a-openocd-esp32-esp-idf-v5.1.2/bin/.openocd-wrapped"  "$@"

$ ls /nix/store/mg9zsdw37qh07sz35kc1jxd886hdj88a-openocd-esp32-esp-idf-v5.1.2/openocd-esp32/share/openocd/scripts
ls: cannot access '/nix/store/mg9zsdw37qh07sz35kc1jxd886hdj88a-openocd-esp32-esp-idf-v5.1.2/openocd-esp32/share/openocd/scripts': No such file or directory

$ ls /nix/store/mg9zsdw37qh07sz35kc1jxd886hdj88a-openocd-esp32-esp-idf-v5.1.2/share/openocd/scripts
bitsbytes.tcl  chip  cpu              fpga       mem_helper.tcl  mmr_helpers.tcl  test
board          cpld  esp-config.json  interface  memory.tcl      target           tools

[cyber-murmel]

I tried to fix this with a small patch. The path in the variable is now correct, but the problem still persists.

$ which openocd
/nix/store/c54yvpq2r818j3b1mqwp3l6awc06pfdj-openocd-esp32-esp-idf-v5.1.2/bin/openocd

$ cat /nix/store/c54yvpq2r818j3b1mqwp3l6awc06pfdj-openocd-esp32-esp-idf-v5.1.2/bin/openocd
#! /nix/store/4vzal97iq3dmrgycj8r0gflrh51p8w1s-bash-5.2p26/bin/bash -e
export OPENOCD_SCRIPTS='/nix/store/c54yvpq2r818j3b1mqwp3l6awc06pfdj-openocd-esp32-esp-idf-v5.1.2/share/openocd/scripts'
exec -a "$0" "/nix/store/c54yvpq2r818j3b1mqwp3l6awc06pfdj-openocd-esp32-esp-idf-v5.1.2/bin/.openocd-wrapped"  "$@" 

$ ls /nix/store/c54yvpq2r818j3b1mqwp3l6awc06pfdj-openocd-esp32-esp-idf-v5.1.2/share/openocd/scripts
bitsbytes.tcl  board  chip  cpld  cpu  esp-config.json  fpga  interface  mem_helper.tcl  memory.tcl  mmr_helpers.tcl  target  test  tools

$ openocd
/nix/store/c54yvpq2r818j3b1mqwp3l6awc06pfdj-openocd-esp32-esp-idf-v5.1.2/bin/openocd: line 3: /nix/store/c54yvpq2r818j3b1mqwp3l6awc06pfdj-openocd-esp32-esp-idf-v5.1.2/bin/.openocd-wrapped: cannot execute: required file not found

[cyber-murmel]

Regardless of the patch, openocd seems to be missing some dynamic libraries.

$ ldd /nix/store/mg9zsdw37qh07sz35kc1jxd886hdj88a-openocd-esp32-esp-idf-v5.1.2/bin/.openocd-wrapped
 linux-vdso.so.1 (0x00007ffe0eebb000)
 libudev.so.1 => not found
 libusb-1.0.so.0 => not found
 libm.so.6 => /nix/store/ksk3rnb0ljx8gngzk19jlmbjyvac4hw6-glibc-2.38-44/lib/libm.so.6 (0x00007f13509bd000)
 libz.so.1 => not found
 libutil.so.1 => /nix/store/ksk3rnb0ljx8gngzk19jlmbjyvac4hw6-glibc-2.38-44/lib/libutil.so.1 (0x00007f13509b8000)
 libdl.so.2 => /nix/store/ksk3rnb0ljx8gngzk19jlmbjyvac4hw6-glibc-2.38-44/lib/libdl.so.2 (0x00007f13509b1000)
 libc.so.6 => /nix/store/ksk3rnb0ljx8gngzk19jlmbjyvac4hw6-glibc-2.38-44/lib/libc.so.6 (0x00007f13507c8000)
 /lib64/ld-linux-x86-64.so.2 => /nix/store/ksk3rnb0ljx8gngzk19jlmbjyvac4hw6-glibc-2.38-44/lib64/ld-linux-x86-64.so.2 (0x00007f1350aa1000)

zlib and libusb1 are part of the FHS env target packages, so I'm a little confused. I noticed that I can just write garbage into the toolFhsEnvTargetPackages package lists and it has no effect on the result.

[cyber-murmel]

Got one bug narrowed down to the wrong string being compared to here. I guess it's supposed to be x86_64-linux line here

The OPENOCD_SCRIPTS variable containing the wrong path might not be that detrimental.

Managed to get an env with working openocd. Will create a PR.