[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lzip-bug] [PATCH] lzip on Windows

From: JonY
Subject: Re: [Lzip-bug] [PATCH] lzip on Windows
Date: Wed, 14 Oct 2009 21:32:47 +0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080213 Thunderbird/ Mnenhy/

On 10/14/2009 18:36, Antonio Diaz Diaz wrote:
Hello JonY,

Thanks for the packages, and thanks to Tino for his feedback.

I have already uploaded the binary package here (see below about the

Tomorrow I'll add the link to the home page, so that the mirrors have
time to catch up.


JonY wrote:
On 10/14/2009 16:03, Tino Lange wrote:
While you're in the mood :-) Do you think that you can port the lzlib
also to win32 / MinGW / MSYS ?

OK, I'll take a look at them over the weekends.


I have just discovered a site maintaining ports of unix tools for
windows (http://gnuwin32.sourceforge.net/). Perhaps you could take a
look and get some ideas. Maybe the lzip port could be placed there or in
a similar site. I don't know.

Placing the lzip source and binaries for gnuwin32 distribution is fine, but distributing the binary form of lzlib could be problematic, mostly due to compiler ABI issues.

I am not yet sure what is the best way of distributing modified sources.
The people at gnuwin32 distributes them as unified diffs

Distributing unified diffs should be fine, but I'm not sure if there are other implications.

In any case, could you please add a line stating something like "Ported
to Windows by <your_name>", or "Patched for Windows by <your_name>", or
"Windows modifications made by <your_name>", (you get the idea), under
the Copyright line in every file you modified in the source package? I
think the GPL requires modified versions be marked as such.

I tend to forget how strict GPL is with copyright assignments. Should I resend the patches and the source tarball?

Also I remember a bug report in Debian explaining the file
share/info/dir should not be included in binary packages. I don't know
if it matters for windows packages.

Windows itself does not have the info(1) tool, but I'll be sure to remove it next time.

BTW, I have just been told that signal handlers for CTRL-C and
CTRL-BREAK do not work for Windows, the program just ends. I don't
think that is will be a huge issue though.

I never expected perfect behaviour of a posix tool on windows.

That is to be expected, Windows doesn't try to be POSIX most of the time (unless you use interix/sua/unix subsystem, but thats a different issue). The MinGW maintainers are also hesitant about adding additional POSIX functions.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]