This is the mail archive of the
mailing list for the Cygwin project.
Re: cygwin patches for gnulib relocation code [Was: Re: Bug in libiconv?]
On 1/27/2011 3:12 PM, Eric Blake wrote:
> On 01/27/2011 11:35 AM, Charles Wilson wrote:
>> Eric (Blake), you're active on the gnulib list. Care to comment?
> Answering with my gnulib maintainer hat on (and yes, I am one of the
> core gnulib maintainers) - Bruno Haible likes to keep cygwin 1.5
> supported in gnulib, and probably will do until at least 3 years after
> cygwin 1.7 was first released, since it is still relatively easy to
> install cygwin 1.5 alongside a modern cygwin and test patches against
> both versions. But Bruno also tends to be the strongest advocate for
> back-compatibility; my feel is that most other active maintainers,
> myself included, are concerned with what builds now, but not worrying
> about porting to an old distro if upgrading to a newer version of the
> same distro achieves the same goal. Then again, all this progreloc
> stuff that triggered this conversation in the first place is Bruno's
> domain, so I can pretty much guess the answer - he'll want to support as
> much as possible, if such support is easy to do.
That's what I suspected (incl. the bit about Bruno's preferences).
> So, answering with my cygwin contributor hat on - it doesn't matter if
> we've fixed the bug for cygwin 1.7.8, gnulib will probably want a
> solution that works with cygwin 1.7.7 for about the next 3-year window,
> as well as a solution for cygwin 1.5.
OK, cygwin added /proc/$PID/maps on 2005-01-29, and so was included in
cygwin-1.5.13 released on 2005-03-01. Therefore, I think Corinna's
changes are fine for upstream gnulib (I'll have a closer look to see if
we need to worry about the cygwin_conv_* 1.5-vs-1.7 issue; but I think
she removed all uses of path conversion code, by staying solely posix
throughout, making that a non-issue).
> But that's gnulib's problem, not
> cygwin's - don't let it stop us from making progress here.
Regardless of how upstream gnulib adapts, I can (and will) patch our
*libiconv* package to DTRT (more unix, less win32; avoid deprecated
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple