Sorry, but this is not really a question as much as some interesting information.
Until yesterday all of my ST applications were working perfectly on a Debian v10.9 installation. Then I started getting this message.....
./STM32_Programmer_CLI: symbol lookup error: ./STM32_Programmer_CLI: undefined symbol: libusb_get_port_number
and some other very similar messages regarding libusb and libgusb. The ST-Link connects without issues, hardware-wise, but when the CubeProgrammer app is running, a click on the "Connect" button with ST-Link as the connection type results in the app closing immediately with the message above. Any other choice of communication just results in no connection but the 'st_link' choice is the killer. But, on the other hand, I can log into the st_link for firmware upgrades and that function works perfectly. There was some other odd machine-wide USB behavior in addition to the CubeProgrammer issue. There is also no connection to the st-link in the CubeIDE app. Spent hours finding the problem and I post it here for future reference. It may be in here somewhere already but it didn't pop up in any searches.
And now for a bit of ST heresy. Yesterday I loaded MPLAB IDE from Microchip. Very confusing compared to CubeIDE which I've gotten used to. From my searches for that libusb issue I finally came across some information about a link placed in /usr/local/lib called libusb-1.0.so.0 that pointed to a file called 'libmchpusb-1.0.so' in the microchip installation directory. I'm not quite sure what the difference is, or what it's supposed to do, but IT APPARENTLY BREAKS THE ST-LINK CONNECTIONS FOR CUBEPROGRAMMER AND CUBEIDE. BEWARE!
Just for the record, removing the link resolved this issue and about a dozen other startup and logging errors for services that were damaged by that link and restored several USB peripheral connections including disk drives and printers. Never saw so much red in the logs.
I've added this after some continuing issues with the microchip application. It appears even with the removal of the software it leaves behind a libusb monitoring program that keeps re-establishing the link from the standard libusb to the microchip version of libusb (libmchpusb.so) that breaks the ST application connections.
TJM
