The `-Wno-unreachable-code-fallthrough` compiler flag suppresses warnings about fallthrough annotations in unreachable code.
In C switch statements, "fallthrough" occurs when execution continues from one case to the next without a break statement. This is often a source of bugs, so modern compilers warn about it. To indicate intentional fallthrough, developers use annotations like `__attribute__((fallthrough))`.
In Cython-generated C code, the `CYTHON_FALLTHROUGH` macro is defined to expand to the appropriate fallthrough annotation for the compiler being used. For example, in `compress.c`:
```c
#define CYTHON_FALLTHROUGH __attribute__((fallthrough))
```
The issue occurs because Cython generates code with conditional branches that may be unreachable on certain platforms or configurations. When these branches contain switch statements with fallthrough annotations, compilers like Clang issue warnings like:
```
warning: fallthrough annotation in unreachable code [-Wunreachable-code-fallthrough]
```
These warnings appear in the generated C code, not in the original Cython source. They're harmless but noisy, cluttering the build output with warnings about code we don't control.
By adding `-Wno-unreachable-code-fallthrough` to the compiler flags in `setup.py`, we specifically tell the compiler to ignore these particular warnings, resulting in a cleaner build output without affecting the actual functionality of the code.
This is a common practice when working with generated code - suppress specific warnings that are unavoidable due to the code generation process while keeping other useful warnings enabled.
`setup.py` hardcoded crypto library paths for OpenBSD, causing build
issue when OpenBSD drops specific OpenSSL version. Solution is to make
paths configurable.
Addresses #8553.
That "failed to map segment from shared object" error msg is not
very helpful. Add a hint that the filesystem needs to be +exec
(== not noexec mounted, like it might be the case for /tmp on
some systems).
Looks like borg's setup.py has hidden the real cause of a cythonize ImportError.
There are basically 2 cases:
- either there is no Cython installed, then the import fails because the module can not be found, or
- there is some issue within Cython and the import fails due to that.
It's important not to hide the real cause, especially if we run into case 2.
case 1 is kind of expected and frequent, case 2 is rare.
this was recently set to a relatively high minimum version when
locating it via pkgconfig was added. this broke the binary builds
on buster and bullseye.
i don't think borg requires a specific libacl version as long as
the api is compatible, so i now set this to 2.2.47 (from 2008).
borg2's new repo format does not need computing crc32 over big amounts of
(content) data any more (we now use xxh64 for that).
thus, having a quick crc32 implementation via libdeflate is not important
enough any more to rectify having libdeflate as a requirement.
if you do not have python >= 3.7, you can still use borg 1.1.x or 1.0.x.
another option is to use the fat binary from github releases, which
includes python and all other stuff needed.
