Hi,
I've made a patch for liblzma to build with MSVC. The main reason fr that is that the provided liblzma.a doesn't work too well with MSVC2011 (it complains about it not compiled with MSVC and not being compatible with their exception hanlding).
The patch is quite big and is basically a port of liblzma to C89. Is someone interested?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Using liblzma.a with MSVC was kind of ugly but I understood that with earlier MSVC versions it worked fine and without warnings. I will update README-Windows.txt.
It seems, that among the compilers in use today, only MSVC and GCC 2 don't support enough C99. GCC 2 is getting more and more rare, and MS isn't interested in supporting modern C. So I'm not so interested in limiting myself to older standards. On the other hand, it isn't a good situation if people have to keep porting XZ Utils to old compilers again and again.
Why do you need static liblzma instead of a DLL? Self-extracting installers are one situation that I'm aware but is there anything else? Installation program usually needs only decompression. I know one person who uses XZ Embedded in an installer because that is C89 and it is also small. Another good alternative is LZMA SDK which supports the .xz format and is compatible with MSVC.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is another need for a MSVC compilation : WinRT (for Windows metro application, including in ARM tablet Windows and next Windows phone 8) can only uses Visual Studio 2012
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would also be highly interested into such a port.
IMHO static linking makes very much sense for many applications, since you'd end up with one executable that can be moved around freely, where as dynamic linkage would require to copy around liblzma.dll too.
If only Windows had some package managing like Linux system, things would be a bit easier…
@thierryba: Would it be possible to publish it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Has anyone tried building liblzma with MSVC 2013 yet? If someone wants to test, I recommend trying with 5.1.3alpha because it has some threading code and thus more things to test.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried to build xz-5.0.5 and basically albeit some MSVC 2013 weirdness I was able to get it to work with some small changes. Apparently it does not like things like this,for example (oddly):
int aa=345;
if (expr == TRUE)
aa = 456;
int bb = aa + 111;
So, changing that to this will work:
int aa=345;
if (expr == TRUE)
{
aa = 456;
}
int bb = aa + 111;
So, that was the type of small changes for liblzma to build on MSVC 2013. However, since xz.exe uses the posix gettimeofday() function and snprintf(), I used the kdewin implementation of these functions so that xz.exe will build. By running the tests on the built DLL, it seems that all is well there in both x86 and x64 flavors, when linked to MSVCRT120.dll (/MD).
Hope this helps.
Last edit: fanc999 2013-12-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Seems that a few other people have noticed the same MSVC bug. It's a fairly new report so with huge luck it might even get fixed. On the other hand, if there aren't too many of those issues in XZ Utils, it may be OK to workaround the MSVC bug.
I think getting liblzma buildable with MSVC is more important than building also xz. I've understood that people want MSVC support for liblzma because that will make it easier to use liblzma when the rest of the application is built with MSVC anyway. xz is a standalone program so MSVC support doesn't matter much, but if the only issues are gettimeofday() and snprintf() it sounds quite good already.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The MSVC bug linked above has been marked as fixed, so I think liblzma from the current xz.git should compile with MSVC 2013 if the latest updates to MSVC have been applied. Note that only liblzma is supported; building the command line tools isn't. There's a config.h for MSVC 2013 in the windows directory. MSVC project files are still missing so you need to pick the files by hand, but that will be fixed.
I don't know yet if support for building the command line tools with MSVC will be included. I guess in most cases it's liblzma for which MSVC support is wanted.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think it's update 2 which seems to still be RC, sorry. For earlier VS2013 a workaround for the bug mentioned above is needed. I don't have a ready-made patch for the current xz.git. Before the final version of VS2013 update 2 is out, you could try https://github.com/Garen/xz. Some of the VS2013 fixes made in xz.git are from the same author.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I uploaded at http://gvollant.free.fr/update_xz2013.zip some file modification :
filter_buffer_decoder.c, filter_buffer_encoder.c, stream_buffer_decoder.c, stream_buffer_encoder.c modification (adding { and }) for VS2013 update 1, and a project for static library, with same tree for source than files
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just used config.h from https://github.com/Garen/xz, and both src/common/sysdefs.h and src/liblzma/check/sha256.c from last git repository http://git.tukaani.org/xz.git , and compile liblzma for both encoding/decoding xz stream with VS2013 update 2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think it should work to build liblzma from xz.git with windows/config.h without modifying any files. If it doesn't, it probably is something short and simple to fix, so I'd like to know what to fix. Thanks! I'll ask Garen about this too on IRC.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've created vs2013 based solution for lzma DLL, lzma static and most utils. It based on the works of Garen & Mārtiņš Možeiko.
It can be found at https://github.com/mindw/xz vs2013_520 branch.
The cmake branch has the build system ported to cmake (only for VS). It enabled me to build xz for Python 2.7 use. (Intel C++ Compiler targeted at VS2008).
Any interest?
-gabi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The 64-bit build uses threading APIs that were added in Vista. The 32-bit version should work on Windows 98 (maybe even 95) and later on i686 (Pentium Pro or Pentium II) or newer. It's documented in doc\README-Windows.txt.
I have understood that 64-bit XP is quite rare and I thought it's OK to use the newer API that is a closer match to the POSIX pthread API. On the other hand the Vista functions don't help much in xz in practice.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I've made a patch for liblzma to build with MSVC. The main reason fr that is that the provided liblzma.a doesn't work too well with MSVC2011 (it complains about it not compiled with MSVC and not being compatible with their exception hanlding).
The patch is quite big and is basically a port of liblzma to C89. Is someone interested?
Using liblzma.a with MSVC was kind of ugly but I understood that with earlier MSVC versions it worked fine and without warnings. I will update README-Windows.txt.
It seems, that among the compilers in use today, only MSVC and GCC 2 don't support enough C99. GCC 2 is getting more and more rare, and MS isn't interested in supporting modern C. So I'm not so interested in limiting myself to older standards. On the other hand, it isn't a good situation if people have to keep porting XZ Utils to old compilers again and again.
Why do you need static liblzma instead of a DLL? Self-extracting installers are one situation that I'm aware but is there anything else? Installation program usually needs only decompression. I know one person who uses XZ Embedded in an installer because that is C89 and it is also small. Another good alternative is LZMA SDK which supports the .xz format and is compatible with MSVC.
I'm very interrested. I'm compiling software with Visual Studio, and building a monolithic executable is important for me. Can you publish it?
There is another need for a MSVC compilation : WinRT (for Windows metro application, including in ARM tablet Windows and next Windows phone 8) can only uses Visual Studio 2012
I would also be highly interested into such a port.
IMHO static linking makes very much sense for many applications, since you'd end up with one executable that can be moved around freely, where as dynamic linkage would require to copy around liblzma.dll too.
If only Windows had some package managing like Linux system, things would be a bit easier…
@thierryba: Would it be possible to publish it?
This is also useful for compiling in Windows Phone 8 project
Microsoft promises that Visual Studio 2013 RTM will have more C99 support. It will be released this year.
http://blogs.msdn.com/b/vcblog/archive/2013/06/28/c-11-14-stl-features-fixes-and-breaking-changes-in-vs-2013.aspx
http://arstechnica.com/information-technology/2013/06/c99-acknowledged-at-last-as-microsoft-lays-out-its-path-to-c14/
Has anyone tried building liblzma with MSVC 2013 yet? If someone wants to test, I recommend trying with 5.1.3alpha because it has some threading code and thus more things to test.
Hello,
I tried to build xz-5.0.5 and basically albeit some MSVC 2013 weirdness I was able to get it to work with some small changes. Apparently it does not like things like this,for example (oddly):
int aa=345;
if (expr == TRUE)
aa = 456;
int bb = aa + 111;
So, changing that to this will work:
int aa=345;
if (expr == TRUE)
{
aa = 456;
}
int bb = aa + 111;
So, that was the type of small changes for liblzma to build on MSVC 2013. However, since xz.exe uses the posix gettimeofday() function and snprintf(), I used the kdewin implementation of these functions so that xz.exe will build. By running the tests on the built DLL, it seems that all is well there in both x86 and x64 flavors, when linked to MSVCRT120.dll (/MD).
Hope this helps.
Last edit: fanc999 2013-12-23
Thanks!
Seems that a few other people have noticed the same MSVC bug. It's a fairly new report so with huge luck it might even get fixed. On the other hand, if there aren't too many of those issues in XZ Utils, it may be OK to workaround the MSVC bug.
I think getting liblzma buildable with MSVC is more important than building also xz. I've understood that people want MSVC support for liblzma because that will make it easier to use liblzma when the rest of the application is built with MSVC anyway. xz is a standalone program so MSVC support doesn't matter much, but if the only issues are gettimeofday() and snprintf() it sounds quite good already.
hello,
if anyone has already build a project and fix to compile liblzma with msvc2013, can he public it?
The MSVC bug linked above has been marked as fixed, so I think liblzma from the current xz.git should compile with MSVC 2013 if the latest updates to MSVC have been applied. Note that only liblzma is supported; building the command line tools isn't. There's a config.h for MSVC 2013 in the windows directory. MSVC project files are still missing so you need to pick the files by hand, but that will be fixed.
I don't know yet if support for building the command line tools with MSVC will be included. I guess in most cases it's liblzma for which MSVC support is wanted.
what update of vs2013 is needed ? update 1?
I think it's update 2 which seems to still be RC, sorry. For earlier VS2013 a workaround for the bug mentioned above is needed. I don't have a ready-made patch for the current xz.git. Before the final version of VS2013 update 2 is out, you could try https://github.com/Garen/xz. Some of the VS2013 fixes made in xz.git are from the same author.
https://github.com/Garen/xz was exxactly what I need :-)
I uploaded at http://gvollant.free.fr/update_xz2013.zip some file modification :
filter_buffer_decoder.c, filter_buffer_encoder.c, stream_buffer_decoder.c, stream_buffer_encoder.c modification (adding { and }) for VS2013 update 1, and a project for static library, with same tree for source than files
Visual Studio 2013 Update 2 is here!
see http://blogs.msdn.com/b/visualstudio/archive/2014/05/12/visual-studio-2013-update-2-is-here.aspx
I just used config.h from https://github.com/Garen/xz, and both src/common/sysdefs.h and src/liblzma/check/sha256.c from last git repository http://git.tukaani.org/xz.git , and compile liblzma for both encoding/decoding xz stream with VS2013 update 2
I think it should work to build liblzma from xz.git with windows/config.h without modifying any files. If it doesn't, it probably is something short and simple to fix, so I'd like to know what to fix. Thanks! I'll ask Garen about this too on IRC.
Hi,
I've created vs2013 based solution for lzma DLL, lzma static and most utils. It based on the works of Garen & Mārtiņš Možeiko.
It can be found at https://github.com/mindw/xz vs2013_520 branch.
The cmake branch has the build system ported to cmake (only for VS). It enabled me to build xz for Python 2.7 use. (Intel C++ Compiler targeted at VS2008).
Any interest?
-gabi
Since you posted to both xz-devel and here, I have replied on xz-devel. Other people interested in the discussion can find the thread from here.
I want to build xzdec.exe on windows (VS 2015) I dont understand how to use Imakefilke.am. Anybody with visual studio solution for this?
xz-5.2.3-windows.7z
bin_x86-64 version of xz.exe doesn't work in Windows XP x64.
Error message:
But another exe files for x64 (lzmadec.exe lzmainfo.exe xzdec.exe) probably work OK.
The 64-bit build uses threading APIs that were added in Vista. The 32-bit version should work on Windows 98 (maybe even 95) and later on i686 (Pentium Pro or Pentium II) or newer. It's documented in doc\README-Windows.txt.
I have understood that 64-bit XP is quite rare and I thought it's OK to use the newer API that is a closer match to the POSIX pthread API. On the other hand the Vista functions don't help much in xz in practice.
@Igor Pavlov
Make also sure you are using v1xx_xp toolset when targetting XP
In other news, it seems like vsnprintf in VS 2015 has finally got C99 conformance.