This is the mail archive of the
mailing list for the GDB project.
Re: [RFA] Avoid error/prompt reversal for mingw
On Mon, Mar 31, 2008 at 05:57:15PM +0200, Pierre Muller wrote:
> > We have spent a lot of time over the last few months getting the
> > testsuite to run on mingw. A mingw-built GDB does not work well
> > with a Cygwin expect. The flush is actually a symptom of a larger
> > problem: isatty returns false when running in expect, but the
> > testsuite is written as if it runs on a terminal.
> But this problem arises both for cygwin and mingw,
> and nevertheless, I never saw the output reversed in Cygwin GDB.
No, isatty works fine in expect if you build a Cygwin GDB. It's only
if you use MSVCRT's isatty that there's a problem.
> > We've got a couple of patches. Some of them we can submit because
> > they're only moderately ugly, but others are just horrible. Can you
> > test a Cygwin-built GDB instead? It's a lot easier, it works a lot
> > better, and it tests more or less the same code.
> I would really be interested in getting the mingw version
> to work as well as the Cygwin, on reason being that I
> would really prefer to be able to use a GDB library without
> cygwin DLL to integrate into my Free Pascal IDE...
> I would also like to be able to test the DJGPP version...
> (I have a predilection for old stuff...)
The mingw version works well. It's only when you try to use it in
combination with Cygwin programs (like expect) that there's trouble.
There are problems with terminal handling, C-c, isatty, and pathnames
when you mix a Cygwin environment with a non-Cygwin GDB. Basically,
I recommend not doing it.
> 1) a patch that uses cygpath to translate cygwin pathes into
> something that Mingw GDB understands,
Interesting, we've done something similar (but it's pretty ugly; I
wasn't planning to submit it).
> 2)a "one line" patch to swallow the "cYg" warnings
> in win32-nat.c
No opinion on this.
> One other really annoying thing after is the
> Dos/Unix line ending stuff...
> Only a small part of the testsuite
> copes correctly with that...
We've got a patch for this one too; that's one I was planning to post.
> Should I conclude from your remarks that
> my patch is not likely to get an approval?
I don't think it's the right solution; that's another patch I could post.