After installing the deb package, st-util fails to start:
> $ st-util
> st-util: error while loading shared libraries: libstlink-shared.so.1:
> cannot open shared object file: No such file or directory
The reason is, no one ran `ldconfig` upon installing the library.
The solution, as per latest Debian recommendations [1], is to add an
ldconfig trigger in debian/triggers, which is what this commit does.
[1] https://www.debian.org/doc/debian-policy/#ldconfig
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
* Fixes for VS2017.
* Added a getopt implementation.
* Added a unistd.h.
* Corrected closing of sockets for Windows versions.
* Fixed gdbserver CMakeLists.txt to play nice with VS2017.
* Fixed include of getopt.h and unistd.h for WIN32.
* Added a unistd.h.
* Corrected closing of sockets for Windows versions.
* Fixed gdbserver CMakeLists.txt to play nice with VS2017.
* Override /MD to /MT for MSVC to match libusb's builds.
* MSVC settings should be if (MSVC).
* Don't busy-wait for long periods in usleep().
* Dynamic link to MSVC libusb binaries.
* Added Visual Studio section to compiling.md.
* Added -D_CRT_NONSTDC_NO_WARNINGS to MSVC flags.
* Prevented some more warnings under MSVC.
It seems that stlink cannot use CMake's standard mechanism to find GTK3.
Cmake's GTK3 detection supports only Unix at the moment.
Therefore, stlink uses pkg-config to find GTK3. The downside of this is
that Cmake's cross-compiler settings are not taken into account. Even if
we're cross-compiling, CMake will find a local installation of GTK3 and
compilation of the GUI fails.
As a simple fix, we skip the GTK3 detection if we're cross-compiling.
(In the long run, we should use a more advanced mechanism to find GTK3.)
* fix wrong libusb extract command
* update libusb to 1.0.21 under windows
* fix few -Wformat warnings
* add usleep realisation for win32
* Get rid of unused defines in mimgw.h
* fix format warning for mingw
* Add prefix SEMIXOST_ to semihost defines.
Fix redefine warnings of mingw.
On 64bit linux all shared objects should go to /usr/lib64. With this
path package maintainters should be able to override library path by
setting STLINK_LIBRARY_PATH.
* Don't use `%zx` because it's unsupported on mingw64
* Also check that no warnings happen on travis
* Prefer `unsigned int` over `unsigned`
* Install libusb through the travis whitelist instead of manually
* Test stlink against clang and gcc through the travis "compiler" flag instead of a manual matrix
* Re-add osx
* Fix warning on gcc
* Revert "fixed support for STM32L011 (#572)"
This reverts commit dc9055362c.
* Revert "Fix possible memory leak (#571)"
This reverts commit 8efd3adc8a.
* Revert "Fix stlink on mingw64 (#569)"
This reverts commit f73ec11abc.
Slyshyk Oleksiy