Set options added by the update to curl 8.12.1.
In particular, now that upstream curl's CMake code depends on
OpenSSL via imported targets from FindOpenSSL, we can let it
handle the transitive dependency on posix threads.
This is present in the upstream libarchive CMake code. We removed it
in commit 59d28b2849 (libarchive: Drop early use of crypto library,
2016-05-03, v3.6.0-rc1~100^2), but didn't record details for why.
Many other changes have been made since then, so the original problem
may no longer occur. Restore the link dependency since it reflects
a real dependency of the implementation.
Compile some third-party libraries with preprocessor definitions that
activate POSIX APIs even when compiler extensions are not enabled.
We already do this in libuv, inherited from the upstream buildsystem.
This extends commit f034b0f663 (CMake compilation: do not use compiler
extensions, 2020-03-14, v3.18.0-rc1~494^2).
Issue: #20454
On SunOS i386, the system headers sometimes define macro names
corresponding to register names, short and with no prefix.
Undefine one that conflicts with our code.
libarchive's crypto library checks use its `config.h` inside the
`try_compile` project. Since commit ade3b16e63 (libarchive: Use KWIML
to get fixed-size integer types, 2020-06-01, v3.18.0-rc1~33^2),
that header depends on KWIML inside CMake. Add the include directory
for KWIML to the crypto library checks. Otherwise, they always fail
due to not finding the KWIML headers, and libarchive decides not
to link the crypto library.
libarchive has other code besides the hash algorithms that depends on
the crypto library if its ENABLE_OPENSSL option is enabled (which in
CMake is controlled by CMAKE_USE_OPENSSL). It seems to be missing some
conditions to link the crypto library in those cases, and instead relies
on at least one of the above-mentioned checks to pass. If they all
fail, and we are using system curl, we might not link the crypto
library.
Fixes: #23234
Move the inclusion added in 3.6.0 to be first. This is the libarchive
convention in all other `.c` sources. It ensures that the configured
`_WIN32_WINNT` value is defined before including any system headers.
Divert LCC compiler as a new one, instead of treating it as GNU.
Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been
passing checks for GNU compilers, so it has been identified as GNU.
Now, with intent of seriously upstreaming its support, it has been
added as a separate LCC compiler, and its version displays not a
supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead
of GNU 7.3.0).
This commit adds its support for detection, and also converts basically
every check like 'is this compiler GNU?' to 'is this compiler GNU or
LCC?'. The only places where this check is untouched, is where it
regards other platforms where LCC is unavailable (primarily non-Linux),
and where it REALLY differs from GNU compiler.
Note: this transition may break software that are already ported to
Elbrus, but hardly relies that LCC will be detected as GNU; still such
software is not known.
Since libarchive commit `aff9809c` (Enable compression level up to 9 for
xz, xar, 7zip, 2020-07-26, v3.5.0~19^2), libarchive fails to initialize
xz compression on AIX with error
Internal error initializing compression library: Cannot allocate memory
Revert to the old limit of level 6 on AIX.
Issue: #22553
Refactoring in commit ade3b16e63 (libarchive: Use KWIML to get
fixed-size integer types, 2020-06-01) accidentally changed the method of
defining `int#_t` types from `typedef` to `#define`. Change it back to
`typedef`.
Reported-by: Rolf Eike Beer <eike@sf-mail.de>
* upstream-LibArchive:
LibArchive 2020-02-11 (3288ebb0)
Also manually restore content from upstream libarchive's main
`CMakeLists.txt` file that was removed by previous commits and
exclude it with `IF(0)` blocks. Do this as an evil merge so
that `git blame -C` can follow the content to upstream.
Fix `archive_string_append_from_wcs_in_codepage` to account for the
already-used portion of the buffer when computing the size of the
remaining buffer for ``WideCharToMultiByte` output.
6c81c6538b libarchive: avoid b64_encode name conflict with Solaris built-in function
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3351
In commit beb991110d (Remove now-unused code once used on IRIX,
2019-01-11, v3.14.0-rc1~167^2) we removed remnants of IRIX support.
Also remove remnants of MIPSpro compiler support.
Backport libarchive commit v3.3.3~16^2 (fix build with LibreSSL 2.7,
2018-04-01). LibreSSL 2.7 adds OpenSSL 1.1 API leading to conflicts on
method names.
Fixes: #18404