The `remove_filename` and `replace_extension` methods compute an offset
between the whole path in a `std::string` and a part of a path in a
`std::string_view`. This is done by subtracting their `.data()`
pointers. However, C++17 adds a non-const `.data()` through which
modification of the string is allowed. This means the copy-on-write
implementation used by the pre-C++11 std::string GNU ABI must reallocate
if the string has been copied. Our subtraction then computes an offset
between two different allocations, which is undefined behavior.
The workaround in commit b3ca4f9ad1 (cm/filesystem: Work around crash
when compiled for CYGWIN/MSYS runtime, 2021-04-22, v3.21.0-rc1~271^2~2)
avoided the problem by calling the non-const `.data()` to reallocate
before constructing the `string_view`. Instead, explicitly call the
const `.data()` method on the string, which does not reallocate.
Fixes: #22090, #23328
The `SafeString` and `ErrorString` classes are deprecated and will be
removed in Docutils 0.21 or later. They help avoid encoding errors
during exception handling in Python <= 2.7, but these days we always
use Python 3 to build the documentation, at least during development,
when error cases are most likely to occur.
Fixes: #24039
The QtHelp Sphinx generation code contains two links to Sphinx issues
that used old, dead BitBucket URLs. Those issues were migrated to
GitHub, so the dead links can be replaced with working ones.
LibreSSL older than 2.6.0 is not supported correctly
in upstream curl, and as a consequence, in libcmcurl.
Such LibreSSL versions can be used in old distros,
like OS Elbrus 4.x and 5.x, so until this fix, CMake
wasn't buildable there either.
Revise and simplify the script from commit d0c9225a7e
(Utilities/Release: Add script to build Qt 6.3.0 Windows binaries,
2022-06-10, v3.24.0-rc1~4^2~5). For `cmake-gui` we only need QtBase.
Also, convert to a `.cmake` script.
Issue: #21902
Mangling was dropped by commit fc22ac115e (zlib: Drop old sources to
make room for a fresh import, 2022-05-26). Restore it for the new
import of upstream zlib.
We previously defined `_POSIX_C_SOURCE` and friends while building
binary packages in order to minimize the version of glibc needed at
runtime. The definitions were added by commit facc240a45
(Utilities/Release: Add docker specs to build and test Linux binaries,
2019-08-23, v3.16.0-rc1~184^2~2), but came from older packaging scripts
that were removed by commit 689fdbfc61 (Utilities/Release: Drop linux64
script in favor of docker build, 2019-08-27, v3.16.0-rc1~184^2). Those
older scripts were meant for use in a hand-maintained environment. Now
that we use base images of old CentOS versions to establish the build
environment, our builds are already limited to older glibc versions
(glibc 2.12 from centos6 on x86_64, and 2.17 from centos7 on aarch64).
Our old system API definitions no longer affect the glibc version
required by the binaries. Drop them to avoid potential conflicts with
system API definitions added by changes like commit f034b0f663 (CMake
compilation: do not use compiler extensions, 2020-03-14, v3.18.0-rc1~494^2)
and commit c7c3e39e4f (Utilities: Activate POSIX APIs even without
compiler extensions, 2022-06-02).
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.
Since commit 4c7c66dcf5 (gitlab-ci: Add jobs to make Windows x86_64 and
i386 packages, 2022-05-19), we use CI jobs to produce Windows binaries.
Revert commit ff929badb3 (Utilities/Release: Add docker specs to
build and test Windows binaries, 2020-05-05, v3.18.0-rc1~203^2~1).
The filesystem inside Windows containers is too slow to support
parallel builds efficiently.
Restore the change from commit cf133ff6b3 (Fix uninitialized variable
access in zlib, 2009-11-18, v2.8.2~705). Their web site claims it does
no harm ( https://www.zlib.net/zlib_faq.html#faq36), but fixing it this
way eliminates the diagnostic.
Brad King