Latest release stlink-1.8.0-win32 doesn't run

[sijk]

• Programmer/board type: STLINK V3
• Operating system an version: Windows
• stlink tools version and/or git commit hash: GitHub release stlink-1.8.0-win32.zip
• stlink commandline tool name: st-util
• Target chip (and board, if applicable): STM32G0B1

Unzipping the GitHub Release stlink-1.8.0-win32.zip and running the executables doesn't work:

$ ./st-util.exe
C:/Users/_/Downloads/stlink-1.8.0-win32/bin/st-util.exe: error while loading shared libraries: libusb-1.0.dll: cannot open shared object file: No such file or directory

If I put a copy of libusb-1.0.dll in that directory then I get the following:

$ ./st-util.exe
st-util 1.8.0
C:/Program Files (x86)/stlink/config/chips: No such file or directory
2024-02-02T11:04:56 WARN common.c: unknown chip id! 0x467
2024-02-02T11:04:56 INFO gdb-server.c: Listening at *:4242...

It's searching for the chip configs at a hard-coded absolute path. If I copy the config files to that path then everything works, but it's a pain to have to do that.

Expected behaviour:

• libusb-1.0.dll is present out of the box,
• Config files are searched for relative to the executable path.

[Nightwalker-87]

@sijk It did run successfully on Windows 11 where it has been tested originally.
Please also check our documentation as well. I can't remember that we ever provided libusb within the package in earlier releases. One would need to look at this as well.

[Nightwalker-87]

Just reviewed: We never published a libusb.dll within the package.
I'm also not aware of that the windows package of the previous release, generated in the same way, is not functional in this context.

[Nightwalker-87]

There appears to be a bug in the compilation routine somewhere regarding the binding of libusb for the standalone binaries which needs to be found.
Please build from source in windows for now to generate working binaries.
This has been re-tested and verified successfully.

[Nightwalker-87]

@sijk I'm confident that a patch will be available soon.
The main issue seems to be resolved by now and work is now focussing on a single remaining aspect on correctly linking config files in the cross build compilation for Windows. The compilation on Windows itself has been refined and a manual copy of the libusb.dll into the binary directory is also no longer necessary. Please stay tuned - it takes the time needed.

[Nightwalker-87]

We still need to find the correct C-Make prefix for the provided config files in our top-level CMakeLists.txt for cross compiling on Linux . (As mentioned before, this does not appear to be an issue when compiling and packing natively on Windows, where ${CMAKE_INSTALL_PREFIX} resolves to \Program Files (x86)\stlink\config\chips within the package.) On Linux we currently have set(CMAKE_CHIPS_DIR ${CMAKE_INSTALL_PREFIX}/config/chips) for WIN32 which does not lead to the intended result in the generated Windows package. This is different compared to the previous release, as this directory path and the config files there were not present by then.

[sijk]

Thanks for the updates. It sounds like the relative path issue should be solvable with the appropriate CMake contortions.

Regarding libusb, all I know is that if I unzip stlink-1.7.0-x86_64-w64-mingw32.zip then I can run bin/st-util.exe successfully, but if I unzip stlink-1.8.0-win32.zip on the same machine then bin/st-util.exe gives the error in the original bug report. You're right that there's no libusb-1.0.dll in the v1.7.0 archive; perhaps it was statically linked?

[Nightwalker-87]

@sijk I know, I've done some testing with it here as well.
For windows libusb should be statically linked, just as the project-internal lib-stlink.
"It sounds like the relative path issue should be solvable with the appropriate CMake contortions." --> True, but seems to be not trivial for shared additional various files ... Specific ideas are gratefully accepted.

[Nightwalker-87]

I believe to have found the issue causing the undesired dynamic/shared linking with libusb during compilation for windows now while thoroughly comparing with the cmake configuration in Release v1.7.0.
However the relative path issue remains unsolved yet. 😕