This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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).

> [snip]
> 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
funcs, etc).


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]