Re: [xz-devel] [PATCH] CMake: Add missing include directory when building the shared library

[Markus Rickert]

Great to see this being tested. Thanks!


Including CMake build files in the repository is very much appreciated 
for building on different platforms and especially on Windows. Thank you 
for that.



The CMakeLists.txt doesn't create config.h. All #defines are set as
compiler options. The config.h files under windows/vs* aren't meant to
be used with CMake. Instead, common_w32res.rc shouldn't read config.h
when it isn't present.

The following patch works with the GNU Autotools based build. Does it
work with CMake + VS2019? It requires that the #defines used for
building C files are passed to the resource compiler too. (If they
aren't, it should give an error.) After a successful build you can
right-click liblzma.dll -> Properties -> Details to see if the info
from the resource file is present.


This way also works, I just tested your patch on my system with VS2019. 
The DLL includes the following info, looks good to me:


 File description: liblzma data compression library
 File version: 5.3.1.0
 Product name: XZ Utils 
 Product version: 5.3.1alpha

Best regards,

Markus Rickert


smime.p7s
Description: S/MIME cryptographic signature

Re: [xz-devel] [PATCH] CMake: Add missing include directory when building the shared library

[Lasse Collin]

On 2020-06-02 Markus Rickert wrote:
> When using CMake to build a shared library with Visual Studio 2019, I
> get an error that the file config.h could not be found:
> 
> cmake -G "Visual Studio 16 2019" -A x64 -DBUILD_SHARED_LIBS=ON ..\xz
> cmake --build . --config Release
> 
> xz\src\common\common_w32res.rc(9): fatal error RC1015: cannot open
> include file 'config.h'. [xz-build\liblzma.vcxproj]

Great to see this being tested. Thanks!

> The file common_w32res.rc has an include for config.h in line 9, but
> the corresponding include directory is missing in the build files.
> The patch fixes this by adding the windows/2019 directory to the list
> of include directories.

The CMakeLists.txt doesn't create config.h. All #defines are set as
compiler options. The config.h files under windows/vs* aren't meant to
be used with CMake. Instead, common_w32res.rc shouldn't read config.h
when it isn't present.

The following patch works with the GNU Autotools based build. Does it
work with CMake + VS2019? It requires that the #defines used for
building C files are passed to the resource compiler too. (If they
aren't, it should give an error.) After a successful build you can
right-click liblzma.dll -> Properties -> Details to see if the info
from the resource file is present.

diff --git a/src/common/common_w32res.rc b/src/common/common_w32res.rc
index a70de34..d05d22e 100644
--- a/src/common/common_w32res.rc
+++ b/src/common/common_w32res.rc
@@ -6,7 +6,9 @@
  */
 
 #include 
-#include "config.h"
+#ifdef HAVE_CONFIG_H
+# include "config.h"
+#endif
 #define LZMA_H_INTERNAL
 #define LZMA_H_INTERNAL_RC
 #include "lzma/version.h"

-- 
Lasse Collin  |  IRC: Larhzu @ IRCnet & Freenode

Re: [xz-devel] LZMA_BUF_ERROR

[Lasse Collin]

Hello!

Sorry for the delay.

On 2020-05-23 K L wrote:
> Could you give us the clue what can be the reason of such buffering
> error and how to overcome it (can it be done in lzma or in libarchive
> code?). Our test data is valid archive (at least several tools can
> read it successfully).

LZMA_BUF_ERROR means that either the input file is truncated/corrupt or
not enough output buffer space is available. The error isn't returned
immediately (allow_buf_error) because it makes one corner case simpler
in some applications, so that's why it is returned only on the third
call.

Perhaps the LZMA data in the .zip file doesn't contain end of stream
(EOS) marker (also known as end-of-payload marker (EOPM)). If the
decoder expect EOPM to be present but the input doesn't have it, the
decoder will think the file is truncated and thus LZMA_BUF_ERROR. The
.zip headers have a bit to indicate the presence of LZMA EOS marker
(sections 4.4.4 and 5.8.9 in APPNOTE.TXT version 6.3.7).

If you decompress with liblzma's lzma_raw_decoder(), then it will
always expect EOPM to be present. This is an API limitation that
doesn't exist in LZMA SDK. This should be improved in liblzma but the
current situation is this.

Internally liblzma can handle LZMA data without EOPM. It is used for
.lzma files and in LZMA2. With the current API, one can write a simple
hack to decode raw LZMA data without EOPM: use lzma_alone_decoder() and
prefix the raw LZMA data with a fake 13-byte .lzma header:

1 byte   LZMA properties
4 bytes  little endian dictionary size
8 bytes  little endian uncompressed size (UINT64_MAX means
 unknown and then (and only then) EOPM must be present)

The first five bytes are the same as the five LZMA properties bytes in
the .zip header. So initialize lzma_alone_decoder(), pass the five
bytes, then pass either the 64-bit uncompressed size (if EOS bit in .zip
headers is unset) or eight 0xFF bytes (if EOS bit in .zip headers is
set), and finally pass the actual LZMA data.

-- 
Lasse Collin  |  IRC: Larhzu @ IRCnet & Freenode