On Thu, Feb 19, 2015 at 12:46:34AM +0200, Lubomir I. Ivanov wrote: > so, i've been bringing this annoying topic multiple times now, > > if Subsurface is built with older libzip, when targeting Win32 there > was this problem where zip_open() from libzip doesn't work with weird > UTF-16 encoded paths...etc... > > so i've just downloaded the tip from their mercurial: > http://hg.nih.at/libzip/ > > and tried opening a file from a UTF-8 encoded source file, while the > filename itself is UTF-16 encoded and it now works (tried multiple > times) as they seem to have changed their API backend. i clearly > remember this didn't work.
Yay! That's a good thing. I have at least one user who is stuck and his downloads from divelogs.de don't work because of this (as far as I can tell). > no special compilation flags required with mingw, though i've just > sent a small patch to their ML, while also asking when the above > functionality was added. > > so when building the Subsurface Win32 package, using the latest libzip > master will not introduce this old potential issue that we found. Of course I read this less than an hour after making (and announcing) 4.4.1 binary packages. Arg. > at some point it was a GSoC task...then i started porting a C++ > version of a minizip wrapper that i had from before, but due to the > actual very low chance of this breaking on user setups it wasn't a > priority. I build everything from source, anyway, so all I need to do is switch to the latest master for libzip? Any unintended consequences of doing so? /D _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface