Re: [xz-devel] minimal liblzma MSVC2013 solution and project
I'm sorry that it takes so long for me to reply. :-( On 2015-06-30 Adam Walling wrote: On Fri, Jun 19, 2015 at 1:42 PM, Lasse Collin lasse.col...@tukaani.org wrote: ... My understanding is that the symbols exported from a DLL should be marked with __declspec(dllexport) when building the DLL. When built with MinGW-w64, this is done in src/liblzma/common/common.h by checking if DLL_EXPORT has been defined by Libtool. Does this work with MSVC as is or does this need to be fixed? My apologies, DLL_EXPORT must indeed be set for the dll to generate the lib. I attached a git diff that does this. Thanks. Was the xzWinTest thing in the patch included intentionally? Do you have an idea how to avoid #defining NDEBUG when building a debug version? It's not essential to have it done now, but I think it's important to do it at some point. The API header src/liblzma/api/lzma.h detects MSVC by checking if _MSC_VER has been defined and avoids using inttypes.h because before MSVC 2013 it didn't exist (I think). Is it OK to replace the line 90 #if defined(_WIN32) defined(_MSC_VER) with this? #if defined(_WIN32) defined(_MSC_VER) _MSC_VER 1800 It doesn't matter when building liblzma itself, but it can matter when compiling something that uses the liblzma API. I believe this is safe; it still builds and runs fine for me with this change, even with consumers of the DLL built before the DLL was rebuilt, and vice versa. In the end it is simply a bunch of typedefs to the same POD type, so I believe this is a safe change Thanks. Committed. -- Lasse Collin | IRC: Larhzu @ IRCnet Freenode
Re: [xz-devel] minimal liblzma MSVC2013 solution and project
On 2015-06-11 Lasse Collin wrote: On 2015-05-28 Adam Walling wrote: Everything is updated at https://github.com/adzm/xz_win now You can also grab them directly at http://adzm.net/xz_win/ Thanks! It looks good now. There are still a few unneeded headers listed, but those should have no effect on the build itself, so they are mostly a cosmetic problem: tuklib_exit.h tuklib_gettext.h tuklib_mbstr.h tuklib_open_stdxxx.h tuklib_progname.h Getting those cleaned up would be nice but it's not essential. I will commit your work next week. I committed the files as is. Thanks. I added some documentation to windows/INSTALL-MSVC.txt. Currently config.h always #defines NDEBUG to disable assertion checks. This isn't desirable for debug builds though so I think it should be fixed. My understanding is that the symbols exported from a DLL should be marked with __declspec(dllexport) when building the DLL. When built with MinGW-w64, this is done in src/liblzma/common/common.h by checking if DLL_EXPORT has been defined by Libtool. Does this work with MSVC as is or does this need to be fixed? The API header src/liblzma/api/lzma.h detects MSVC by checking if _MSC_VER has been defined and avoids using inttypes.h because before MSVC 2013 it didn't exist (I think). Is it OK to replace the line 90 #if defined(_WIN32) defined(_MSC_VER) with this? #if defined(_WIN32) defined(_MSC_VER) _MSC_VER 1800 It doesn't matter when building liblzma itself, but it can matter when compiling something that uses the liblzma API. -- Lasse Collin | IRC: Larhzu @ IRCnet Freenode
Re: [xz-devel] minimal liblzma MSVC2013 solution and project
Adam Hi, In case you've missed this - you can also try the CMake version at https://github.com/mindw/xz . It has all utilities ported as well. Please note that it is a very bad idea to mix runtimes on Windows - http://blogs.msdn.com/b/oldnewthing/archive/2014/04/11/10516280.aspx . -g -gabi On Thu, May 28, 2015 at 5:37 PM, Adam Walling adam.wall...@gmail.com wrote: On Tue, May 26, 2015 at 2:57 PM, Lasse Collin lasse.col...@tukaani.org wrote: On 2015-05-22 Adam Walling wrote: This is a minimal solution and two project files which allow liblzma to be built with MSVC2013. I did not attempt to include any tools or tests, or address any warnings. However, it is functional, so I would like to share this as an alternative to the 'Fairly Complete' solution / project. This does not require any changes to the code itself, just adding the files within the /windows subdirectory is enough. liblzma.vcxproj builds the static library liblzma_dll.vcxproj builds a dll Thanks! This could be a good start since I still think that liblzma is the important part of XZ Utils to get working with MSVC. xz.exe can wait a little longer. There are a few extra files in the build: - Of the tuklib_*.c files, liblzma only needs tuklib_physmem.c and tuklib_cpucores.c. - rangecoder/price_tablegen.c must not be included. It's a standalone tool to generate price_table.c. Removed, thanks! It's nice to see that you got liblzma_w32res.rc to build as is. In the other thread there were problems with the resource files and using CMake was considered, but clearly it's not needed at least for liblzma DLL. Seems that the DLL file becomes liblzma_dll.dll. I wonder if that is a good thing. As I understand this, the MSVC-built liblzma DLL should be compatible with the DLL built with MinGW-w64 so naming it just liblzma.dll should be more convenient, but perhaps I'm missing something. Now using liblzma.dll target path as it should. With the above issues fixed, I could like to commit the project files and include them in XZ Utils 5.2.2. This doesn't make the other MSVC thread deprecated yet: I should fix a few more warnings, and perhaps xz.exe could be made MSVC compatible some day too. Everything is updated at https://github.com/adzm/xz_win now You can also grab them directly at http://adzm.net/xz_win/ including a patch that fixes all warnings in MSVC2013 when building: http://adzm.net/xz_win/msvc2013_warnings.patch -- Lasse Collin | IRC: Larhzu @ IRCnet Freenode -- - Adam D. Walling
