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)
If common_w32res.rc is modified, the resource files need to be rebuilt.
In contrast, the liblzma*.map files truly are link dependencies.
(cherry picked from commit da4f275bd1c18b897e5c2dd0043546de3accce0a)
CMakeLists.txt was using xzdec_w32res.rc for both xzdec and lzmadec.
Fixes: 998d0b29536094a89cf385a3b894e157db1ccefe
(cherry picked from commit dc7b9f24b737e4e55bcbbdde6754883f991c2cfb)
The MB output can overflow with huge numbers. Most likely these are
invalid .lzma files anyway, but let's avoid garbage output.
lzmadec was adapted from LZMA Utils. The original code with this bug
was written in 2005, over 19 years ago.
Co-authored-by: Lasse Collin <lasse.collin@tukaani.org>
Closes: https://github.com/tukaani-project/xz/pull/144
(cherry picked from commit 76cfd0a9bb33ae8e534b1f73f6359dc825589f2f)
"xzdec -M123" exited with exit status 1 without printing
any messages. The "M:" entry should have been removed when
the memory usage limiter support was removed from xzdec.
Fixes: 792331bdee706aa852a78b171040ebf814c6f3ae
Closes: https://github.com/tukaani-project/xz/pull/143
[ Lasse: Commit message edits ]
(cherry picked from commit 78355aebb7fb654302e5e33692ba109909dacaff)
Differences to the zh_CN.po file from the Translation Project:
- Two uses of \v were fixed.
- Missing "OPTS" translation in --riscv[=OPTS] was copied from
previous lines.
- "make update-po" was run to remove line numbers from comments.
(cherry picked from commit 68c54e45d042add64a4cb44bfc87ca74d29b87e2)
Differences to the ca.po file from the Translation Project:
- An overlong line translating --filters-help was wrapped.
- "make update-po" was used to remove line numbers from the comments
to match the changes in fccebe2b4fd513488fc920e4dac32562ed3c7637
and 093490b58271e9424ce38a7b1b38bcf61b9c86c6. xz.pot in the TP
is older than these commits.
(cherry picked from commit 2230692aa1bcebb586100183831e3daf1714d60a)
Support for instruction "movzw" without suffix in "GNU as" was
added in commit [1] and stabilized in binutils 2.27, released
in August 2016. Earlier systems don't accept this instruction
without a suffix, making range_decoder.h's inline assembly
unable to build on old systems such as Ubuntu 16.04, creating
error messages like:
lzma_decoder.c: Assembler messages:
lzma_decoder.c:371: Error: no such instruction: `movzw 2(%r11),%esi'
lzma_decoder.c:373: Error: no such instruction: `movzw 4(%r11),%edi'
lzma_decoder.c:388: Error: no such instruction: `movzw 6(%r11),%edx'
lzma_decoder.c:398: Error: no such instruction: `movzw (%r11,%r14,4),%esi'
Change "movzw" to "movzwl" for compatibility.
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c07315e0c610e0e3317b4c02266f81793df253d2
Suggested-by: Lasse Collin <lasse.collin@tukaani.org>
Tested-by: Yifeng Li <tomli@tomli.me>
Signed-off-by: Yifeng Li <tomli@tomli.me>
Fixes: 3182a330c1512cc1f5c87b5c5a272578e60a5158
Fixes: https://github.com/tukaani-project/xz/issues/121
Closes: https://github.com/tukaani-project/xz/pull/136
(cherry picked from commit 6cd7c8607843c337edfe2c472aa316602a393754)
It won't be implemented. find + xargs is more flexible, for example,
it allows compressing small files in parallel. An example for that
has been included in the xz man page since 2010.
(cherry picked from commit baecfa142644eb5f5c6dd6f8e2f531c362fa3747)
The liblzma target was recently changed to link against Threads::Threads
with the PRIVATE keyword. I had forgotten that xz itself depends on
pthreads too due to pthread_sigmask(). Thus, the build broke when
building shared liblzma and pthread_sigmask() wasn't in libc.
Thanks to Peter Seiderer for the bug report.
Fixes: ac05f1b0d7cda1e7ae79775a8dfecc54601d7f1c
Fixes: https://github.com/tukaani-project/xz/issues/129#issuecomment-2204522994
(cherry picked from commit b3e53122f42796aaebd767bab920cf7bedf69966)
This addresses the issue I mentioned in
6c095a98fbec70b790253a663173ecdb669108c4 and speeds up the Valgrind
job a bit, because non-xz tools aren't run unnecessarily with
Valgrind by the script tests.
(cherry picked from commit 7e99856f66c07852c4e0de7aa01951e9147d86b0)
It shouldn't make any difference because LIBS should be empty
at that point in configure. But prepending is the correct way
because in general the libraries being added might require other
libraries that come later on the command line.
(cherry picked from commit 2402e8a1ae92676fa0d4cb1b761d7f62f005c098)
It's more robust in case the compiler allows pre-C99 implicit function
declarations. If an x86 intrinsic is missing and gets treated as
implicit function, the linking step will very probably fail. This
isn't the only way to workaround implicit function declarations but
it might be the simplest and cleanest.
The problem hasn't been observed in the wild.
There are a couple more AC_COMPILE_IFELSE uses in configure.ac.
Of these, Landlock check calls prctl() and in theory could have
the same problem. In practice it doesn't as the check program
looks for several other things too. However, it was changed to
AC_LINK_IFELSE still to look more correct.
Similarly, m4/tuklib_cpucores.m4 and m4/tuklib_physmem.m4 were
updated although they haven't given any trouble either. They
have worked all these years because those check programs rely
on specific headers and types: if headers or types are missing,
compilation will fail. Using the linker makes these checks more
similar to the ones in cmake/tuklib_*.cmake which always link.
(cherry picked from commit 7bb46f2b7b3989c1b589a247a251470f65e91cda)
AC_COMPILE_IFELSE needed -Werror because Clang <= 14 would merely
warn about the unsupported attribute and implicit function declaration.
Changing to AC_LINK_IFELSE handles the implicit declaration because
the symbol __crc32d is unlikely to exist in libc.
Note that the other part of the check is that #include <arm_acle.h>
must work. If the header is missing, most compilers give an error
and the linking step won't be attempted.
Avoiding -Werror makes the check more robust in case CFLAGS contains
warning flags that break -Werror anyway (but this isn't the only check
in configure.ac that has this problem). Using AC_LINK_IFELSE also makes
the check more similar to how it is done in CMakeLists.txt.
(cherry picked from commit 35eb57355ad1c415a838d26192d5af84abb7cf39)
It's nice to keep these in sync. The use of main() will later allow
AC_LINK_IFELSE usage too which may avoid the more fragile -Werror.
(cherry picked from commit 5a728813c378cc3c4c9c95793762452418d08f1b)
I had missed this simpler method before. It does create a dependency
so that if .in.h changes the copying is done again.
(cherry picked from commit de215a0517645d16343f3a5336d3df884a4f665f)
It was weird to add CMAKE_THREAD_LIBS_INIT in CMAKE_REQUIRED_LIBRARIES
only if CLOCK_MONOTONIC is available. Alternative would be to remove
the thread libs from CMAKE_REQUIRED_LIBRARIES after the check for
pthread_condattr_setclock() but keeping the libs should be fine too.
Then it's ready in case more pthread functions were wanted some day.
(cherry picked from commit e620f35097c0ad20cd76d8258750aa706758ced9)
In CMake, check_c_source_compiles() always links too. With
link-time optimization, unused functions may get omitted if
main() doesn't depend on them. Consider the following which
tries to check if somefunction() is available when <someheader.h>
has been included:
#include <someheader.h>
int foo(void) { return somefunction(); }
int main(void) { return 0; }
LTO may omit foo() completely because the program as a whole doesn't
need it and then the program will link even if the symbol somefunction
isn't available in libc or other library being linked in, and then
the test may pass when it shouldn't.
What happens if <someheader.h> doesn't declare somefunction()?
Shouldn't the test fail in the compilation phase already? It should
but many compilers don't follow the C99 and later standards that
prohibit implicit function declarations. Instead such compilers
assume that somefunction() exists, compilation succeeds (with a
warning), and then linker with LTO omits the call to somefunction().
Change the tests so that they are part of main(). If compiler accepts
implicitly declared functions, LTO cannot omit them because it has to
assume that they might have side effects and thus linking will fail.
On the other hand, if the functions/intrinsics being used are supported,
they might get optimized away but in that case it's fine because they
really are supported.
It is fine to use __attribute__((target(...))) for main(). At least
it works with GCC 4.9 to 14.1 on x86-64.
Reported-by: Sam James <sam@gentoo.org>
(cherry picked from commit 114cba69dbb96003e676c8c87a2e9943b12d065f)
Check for the wrong triplet from config.guess and override it with
the --build option on the configure command line. Then i386 assembly
autodetection will work.
These Ubuntu versions (and as of writing, also Debian unstable)
ship config.guess version 2022-01-09 which contains a bug that
was fixed in version 2022-05-08. It results in a wrong configure
triplet when using CC="gcc -m32" to build i386 binaries.
Upstream fix:
https://git.savannah.gnu.org/cgit/config.git/commit/?id=f56a7140386d08a531bcfd444d632b28c61a6329
More information:
https://mail.gnu.org/archive/html/config-patches/2022-05/msg00003.html
(cherry picked from commit 1bf83cded2955282fe1a868f08c83d4e5d6dca4a)
The old method put it in CFLAGS which is a wrong place because
config.guess doesn't read CFLAGS.
(cherry picked from commit dbcdabf68fee9ed694b68c3a82e6adbeff20b679)
CC from environment is used to initialize CMAKE_C_COMPILER so
setting CMAKE_C_COMPILER explicitly isn't needed.
The syntax in ci_build.bash was broken in case one wished to put
spaces in CC.
(cherry picked from commit 0c1e6d900bac127464fb30a854776e1810ab5f16)
This makes no difference yet because -lrt is currently the only option
that might be added to LIBS.
(cherry picked from commit 75ce4797d49621710e6da95d8cb91541028c6d68)
This way pthread options aren't passed to the linker when linking
against shared liblzma but they are still passed when linking against
static liblzma. (Also, one never needs the include path of the
threading library to use liblzma since liblzma's API headers
don't #include <pthread.h>. But <pthread.h> tends to be in the
default include path so here this change makes no difference.)
One cannot mix target_link_libraries() calls that use the scope
(PRIVATE, PUBLIC, or INTERFACE) keyword and calls that don't use it.
The calls without the keyword are like PUBLIC except perhaps when
they aren't, or something like that... It seems best to always
specify a scope keyword as the meanings of those three keywords
at least are clear.
(cherry picked from commit ac05f1b0d7cda1e7ae79775a8dfecc54601d7f1c)
This shouldn't make much difference in practice as on Windows
no flags are needed anyway and unitialized variable (when threading
is disabled) expands to empty. But it's clearer this way.
(cherry picked from commit 2aecffe0f0e14f3ef635e8cd7b405420f2385de2)
vcpkg doesn't specify the newline type so it should be fine to
use native newlines in liblzma.pc on Windows.
(cherry picked from commit 5ca96a93488d0f5a530c78b274cac317453807ff)
Now liblzma.pc can be relocatable only if using CMake >= 3.20
but that should be OK as now we shouldn't get broken liblzma.pc
if CMAKE_INSTALL_LIBDIR or CMAKE_INSTALL_INCLUDEDIR contain an
absolute path.
Thanks to Eli Schwartz.
(cherry picked from commit ebd155c3a1b87411edae06d3bdaa9659ec057522)
On E2K the function compiles only due to compiler emulation but the
function is never used. It's cleaner to omit the function when it's
not needed even though it's a "static inline" function.
Thanks to Ilya Kurdyukov.
(cherry picked from commit 30a2d5d51006301a3ddab5ef1f5ff0a9d74dce6f)
