Instead of using distutils/setuptools for installing the Python code,
just install it into our own Python directory.
Distutils is being removed from Python, and setuptools doesn't work well
when trying to install into your own location. For our usage its just
simpler to install with make.
In addition to removing the configure check for distutils, also remove
the check for pyyaml. This lets the user install pyyaml after Suricata
is installed, and Suricata-Update does handle this case gracefully.
Issue: #5313
(cherry picked from commit 9a1d6af858)
Issue: 4973
This commit makes stack-trace on fault configurable by
adding "--enable-libunwind" as a configure option.
By default, or if "--enable-libunwind=no" is specified, the libunwind
library will not be configured.
When "--enable-libunwind=yes" is specified, libunwind will be used iff
it can be found in one of the standard library locations.
This commit adds support for enabling libunwind -- a library that can be
used to display stack information.
Libunwind is enabled and used by Suricata if present during
configuration. A diagnostic message is displayed if libunwind
cannot be found.
(cherry picked from commit 303dd29b50)
This commit adds a probe for a non-portable function to be used in
diagnostic debug display of a thread's stack size.
(cherry picked from commit deb49862cd)
Prior to Rust 1.44, Cargo would name static libs with the .lib
extension. 1.44 changes this extension to .a when running under
a GNU environment on Windows like msys to make it more similar
to other unix environments.
Now assume static library name to be the same on Windows and
unix, but rename the .lib if found to still support older
versions of Rust on Windows.
Borrow a macro from https://github.com/popzxc/stdext-rs that
will give us the Rust function name in SCLog messages in Rust.
As this trick only works on Rust 1.38 and newer, keep the old
macro around and set a feature based on a Rust version test
done during ./configure.
Only run cbindgen when necessary. This is a bit tricky. When
building a dist we want to unconditionally build the headers.
When going through a "make; sudo make install" type process,
cbindgen should not be run as the headers already exist, are
valid, and the environment under sudo is more often than
not suitable to pick up the Rust toolchains when installed
with rustup.
For the normal "make" case we have the gen/rust-bindings.h file
depend on library file, this will cause it to only be rebuilt
if the code was modified.
For "make dist" we unconditionally create "dist/rust-bindings.h".
This means the generated file could be in 2 locations, so update
configure.ac, and the library search find to find it.
The "gen/rust-bindings.h" should be picked up first if it exists,
for those who develop from a dist archive where "dist/rust-bindings.h"
also exists.
Not completely happy having the same file in 2 locations, but not
sure how else to get the dependency tracking correct.