This only affects builds with UCRT. With legacy MSVCRT, the replacement
functions are always enabled.
Omitting the MinGW-w64 replacements saves over 20 KiB per executable.
The downside is that --enable-small or XZ_SMALL=ON disables thousand
separator support in xz messages. If someone is OK with the slower
speed of slightly smaller builds, lack of thousand separators won't
matter.
Don't override __USE_MINGW_ANSI_STDIO if it is already defined (via
CPPFLAGS or such method).
(cherry picked from commit 4eae859ae8ad7072eaa74aeaee79a2c3c12c55cb)
Use also LC_COLLATE=C to make the sorting locale-independent.
Sorting makes the file order reproducible.
(cherry picked from commit 950da11ce09c90412dcbca29689575037640667a)
When the 8-byte method was enabled for ARM64, a check for endianness
wasn't added. This broke the LZMA/LZMA2 encoder. Test suite caught it.
Fixes: cd64dd70d5665b6048829c45772d08606f44672e
Co-authored-by: Marcus Comstedt <marcus@mc.pp.se>
(cherry picked from commit 150356207c8d6a3e0af465b676430d19d62f884c)
While MSVCRT builds are possible, UCRT works better with UTF-8.
A 32-bit build is included still but hopefully it's not actually
needed anymore.
(cherry picked from commit 0dfc67d37ebb038be8a9b17b536d1b561d52e81a)
I rewrapped a few overlong lines. Those edits aren't in the
Translation Project. Automatic wrapping in the master branch
means that these strings need to be updated soon anyway.
lzma_str_to_filters() may call parse_lzma12_preset() in two ways. The
call from str_to_filters() detects the string type from the first
character(s) and as a side-effect it validates the first digit of
the preset string. So this change makes no difference there.
However, the call from parse_options() doesn't pre-validate the string.
parse_lzma12_preset() will return an invalid value which is passed to
lzma_lzma_preset() which safely rejects it. The bug still affects the
the error message:
$ xz --filters=lzma2:preset=X
xz: Error in --filters=FILTERS option:
xz: lzma2:preset=X
xz: ^
xz: Unsupported preset
After the fix:
$ xz --filters=lzma2:preset=X
xz: Error in --filters=FILTERS option:
xz: lzma2:preset=X
xz: ^
xz: Unsupported preset
The ^ now correctly points to the X and not past it because the X itself
is the problematic character.
Fixes: cedeeca2ea6ada5b0411b2ae10d7a859e837f203
(cherry picked from commit 75107217670a97b7b772833669d88c3c2f188e37)
Forgetting the argument (or not using = to separate the option from
the argument) resulted in lzma_str_to_filters() being called with NULL
as input string argument. The function handles it fine but xz passes
the NULL to printf() too:
$ xz --filters
xz: Error in --filters=FILTERS option:
xz: (null)
xz: ^
xz: Unexpected NULL pointer argument(s) to lzma_str_to_filters()
Now it's correct:
$ xz --filters
xz: option '--filters' requires an argument
The --filters-help option doesn't take any arguments.
Fixes: 9ded880a0221f4d1256845fc4ab957ffd377c760
Fixes: d6af7f347077b22403133239592e478931307759
Fixes: a165d7df1964121eb9df715e6f836a31c865beef
(cherry picked from commit 52ff32433734d03befd85a5bf00fba77d6501455)
This fix is similar to 48ff3f06521ca326996ab9a04d1b342098960427.
Fixes: d74fb5f060b76db709b50f5fd37490394e52f975
(cherry picked from commit 2655c81b5e92278b0fd51f6537c1116f8349b02a)
Also remove the recently-added workaround from tuklib_gettext.h.
Requiring a new enough gettext-runtime is cleaner. I guess it's
mostly MSYS2 where xz is built with translation support, so once
MSYS2 has Gettext >= 0.23.1, this requirement shouldn't be a problem
in practice.
(cherry picked from commit 16821252c504071f5c2012e415e59cbf5fb79820)
It's the default in git-log. Specifying it explicitly is good in case
a user has set format.pretty to a different value.
(cherry picked from commit ea21c76aa2406ba06ac154fe57741734c04f260f)
The DESCRIPTION section always explained it, and the OPTIONS section
only described the differences to the default behavior. However, new
users in a hurry may skip reading DESCRIPTION. The default behavior
is a bit dangerous, thus it's good to repeat in --compress and
--decompress docs that source file is removed after successful operation.
Fixes: https://github.com/tukaani-project/xz/issues/150
(cherry picked from commit 653732bd6f06d8f465bf353bf6e1c16f1405b906)
liblzma and xz can't be compiled as a unity/jumbo build because of
redeclarations and type name reuse. The CMake documentation recommends
setting UNITY_BUILD to false in this case.
This is especially important if we're compiled as a subproject and the
consumer wants to use CMAKE_UNITY_BUILD=ON for the rest of their code
base.
Closes: https://github.com/tukaani-project/xz/pull/158
(cherry picked from commit bf6da9a573a780cd1a7fb1728ef55d09e58dad11)
See the comment. In this package, locale is set at program startup and
not changed later, so the point (2) in the comment isn't a problem.
Fixes: 46ee0061629fb075d61d83839e14dd193337af59
(cherry picked from commit b40e3321a7fb9dfdf8ffb30e7e0788c2f0abc941)
xzdec isn't translated and doesn't need libintl on Windows even
when NLS is enabled, thus libintl_setlocale() cannot interfere
with the locale settings. Thus, standard setlocale() works perfectly.
In the commit 78868b6e, the explanation in the commit message is wrong.
Fixes: 78868b6ed63fa4c89f73e3dfed27abfb8b0d46db
(cherry picked from commit d6796f9ce5359faaaed82926c1735aee3694430f)
Only leave the FindFileFirstA() notes from 20dfca81, reverting
the incorrect setlocale() notes. On Windows, Gettext's <libintl.h>
overrides setlocale() with libintl_setlocale() wrapper. I hadn't
noticed this, and thus my conclusions were wrong.
Fixes: 20dfca8171dad4c64785ac61d5b68972c444877b
(cherry picked from commit e607329a615759f1519016595dd38df7c89208f2)
If wcwidth() isn't available (Windows), previously it was assumed
that one byte == one column in the terminal. Now it is assumed that
one multibyte character == one column. This works better with UTF-8.
Languages that only use single-width characters without any combining
characters should work correctly with this.
In xz, none of po/*.po contain combining characters and only ko.po,
zh_CN.po, and zh_TW.po contain fullwidth characters. Thus, "only"
those three translations in xz are broken on Windows with the
UTF-8 code page. Broken means that column headings in xz -lvv and
(only in the master branch) strings in --long-help are misaligned,
so it's not a huge problem. I don't know if those three languages
displayed perfectly before the UTF-8 change because I hadn't tested
translations with native Windows builds before.
Fixes: 46ee0061629fb075d61d83839e14dd193337af59
(cherry picked from commit b797c44c42ea54fe1c52722a2fca0c9618575598)
xzdec isn't translated and didn't have locale-specific behavior
in the past. On Windows with UTF-8 in the application manifest,
setting the locale makes a difference though:
- Without any setlocale() call, non-ASCII filenames don't display
properly in Command Prompt unless one first uses "chcp 65001"
to set the console code page to UTF-8.
- setlocale(LC_ALL, "") is enough to make non-ASCII filenames
print correctly in Command Prompt without using "chcp 65001",
assuming that the non-UTF-8 code page (like 850) supports
those non-ASCII characters.
- setlocale(LC_ALL, ".UTF8") is even better because then mbrtowc() and
such functions use an UTF-8 locale instead of a legacy code page.
The tuklib_gettext_setlocale() macro takes care of this (without
enabling any translations).
Fixes: 46ee0061629fb075d61d83839e14dd193337af59
(cherry picked from commit 78868b6ed63fa4c89f73e3dfed27abfb8b0d46db)
XZ Utils 5.6.3 set the active code page to UTF-8 to fix CVE-2024-47611.
This wasn't paired with UCRT-specific setlocale(LC_ALL, ".UTF8"), thus
non-ASCII characters from translations became mojibake.
Fixes: 46ee0061629fb075d61d83839e14dd193337af59
(cherry picked from commit 0d0b574cc45045d6150d397776340c068df59e2a)
Also warn about unpaired surrogates and (somewhat UTF-8-specific)
MAX_PATH issue in FindFirstFileA().
Fixes: 46ee0061629fb075d61d83839e14dd193337af59
(cherry picked from commit 20dfca8171dad4c64785ac61d5b68972c444877b)
If the early pledge() call on OpenBSD fails, it calls my_errorf()
which requires the "progname" variable.
Fixes: d74fb5f060b76db709b50f5fd37490394e52f975
(cherry picked from commit 4e936f234056e5831013ed922145b666b04bb1e3)
With CMake 3.31, there were a few warnings from
CMP0177 "install() DESTINATION paths are normalized".
These occurred because the install(FILES) command in
my_install_man_lang() is called with a DESTINATION path
that contains two consecutive slashes, for example,
"share/man//man1". Such a path is for the English man pages.
With translated man pages, the language code goes between
the slashes. The warning was probably triggered because the
extra slash gets removed by the normalization.
(cherry picked from commit 61feaf681bd793dc5c919732b44bca7dcf2ed1b8)
Checked the changes and they're all innocuous. This should hopefully
fix the "externally managed" pip error in these jobs that started
recently.
(cherry picked from commit dbca3d078ec581600600abebbb18769d3d713914)
v5.2 didn't build with CMake. Other branches had
include(CMakePushCheckState) in top-level CMakeLists.txt
which made the build work.
Fixes: 597f49b61475438a43a417236989b2acc968a686
(cherry picked from commit be4bf94446b6286a5dffdde85fc1d21448f4edff)
This ensures that the test programs get executed the same way as
the binaries that are installed.
(cherry picked from commit 74702ee00ecfd080d8ab11118cd25dbe6c437ec0)
IMPORTANT: This includes a security fix to command line tool
argument handling.
Some toolchains embed an application manifest by default to declare
UAC-compliance. Some also declare compatibility with Vista/8/8.1/10/11
to let the app access features newer than those of Vista.
We want all the above but also two more things:
- Declare that the app is long path aware to support paths longer
than 259 characters (this may also require a registry change).
- Force the code page to UTF-8. This allows the command line tools
to access files whose names contain characters that don't exist
in the current legacy code page (except unpaired surrogates).
The UTF-8 code page also fixes security issues in command line
argument handling which can be exploited with malicious filenames.
See the new file w32_application.manifest.comments.txt.
Thanks to Orange Tsai and splitline from DEVCORE Research Team
for discovering this issue.
Thanks to Vijay Sarvepalli for reporting the issue to me.
Thanks to Kelvin Lee for testing with MSVC and helping with
the required build system fixes.
(cherry picked from commit 46ee0061629fb075d61d83839e14dd193337af59)
Now the information in the "Details" tab in the file properties
dialog matches the naming convention of Cygwin and MSYS2. This
is only a cosmetic change.
(cherry picked from commit dad153091552b52a41b95ec4981c6951f1cae487)
LANGUAGE and VS_VERSION_INFO begin new statements so put an empty line
between them.
(cherry picked from commit 8940ecb96fe9f0f2a9cfb8b66fe9ed31ffbea904)
Autotools-based build has always done this so this is for consistency.
However, the CMake build won't create the DEF file when building
for Cygwin or MSYS2 because in that context it should be useless.
(If Cygwin or MSYS2 is used to host building of normal Windows
binaries then the DEF file is still created.)
(cherry picked from commit c3b9dad07d3fd9319f88386b7095019bcea45ce1)
