This is the mail archive of the
mailing list for the Cygwin project.
Re: Problem compiling perl module Term::ReadKey under cygwin
> I'm not sure who the "everyone" you're referring to but I've only seen
> only one thing that could be characterised as criticism. I thanked
> someone for understanding the reason for the change to Cygwin.
> Hopefully that was not seen as a slam against the person who submitted
> the patch.
> I am also thankful that someone took the time to track down what needed
> to be changed but I haven't reached a point where I think there is a
> crying need to change cygwin back to its old behavior. I try to
> minimize the number of options available for the CYGWIN environment
> variable, too. This is just in the interests of not presenting too many
> things for people to tweak that make problem debugging harder.
I understand. There are already too many CYGWIN options for me to keep
> >FWIW, I *did* track down this error. It's actually in libiberty, not
> >perl, and is the result cygwin's unusual status as a unix platform
> >running under windows: _WIN32 is defined, so libiberty uses '\' as the
> >path separator. Once I figure out to whom the patch should go (since
> >everybody seems to maintain their own version -- gcc, cygwin, binutils,
> >etc) I'll submit it.
> gcc and binutils have somewhat separate versions of libiberty. Cygwin
> uses the binutils version. The binutils version is imported from gcc
> But you don't need to do anything. It's already fixed in CVS in both
> binutils and gcc (and has been for some time) and I've made an
> experimental version of binutils available with the fix.
Well, that serves me right for debugging with the tarball versions
instead of CVS. :-)
Want to unsubscribe from this list?
Send a message to email@example.com