On 2015-05-28 Gabi Davar wrote: > Please note that it is a very bad idea to mix runtimes on Windows
I had thought it's not a problem (excluding debugging) with liblzma because I had remembered that liblzma doesn't expose any libc/runtime- specific things (like file descriptors) via its API. Now that I checked the API functions, I see I was wrong and there are a few functions that allocate memory and expect the application to free it instead of calling some other liblzma function to free it. This is obviously won't work if the runtimes differ. List of the functions: lzma_block_header_decode lzma_filters_copy lzma_properties_decode lzma_filter_flags_decode The good news is that most applications have no need to use those functions since they aren't needed for the most common tasks. xz uses some of those though, so using e.g. MinGW-w64-built xz.exe with MSVC-built liblzma.dll cannot work to decompress .lzma files or to view information about .xz files with "xz -lvv" (only the max verbosity level should be affected). I haven't actually tried mixing MinGW-w64 and MSVC code this way yet, but I will try some day for fun. Those functions and many other liblzma functions take a pointer to lzma_allocator structure which can be used to specify different memory allocation functions than malloc() and free(). This way the problem can be worked around in theory, but I guess few would figure it out in case they needed those few functions. So yeah, mixing runtimes on Windows is bad. It's hard to do it correctly for every detail. -- Lasse Collin | IRC: Larhzu @ IRCnet & Freenode