readline rebase 5.1->6.2?

readline rebase 5.1->6.2?

[Jan Kratochvil]

Hi,

it is a bity pity the sourceware tree still bundles readline-5.1 while distros
build GDB with readline less than 5 years old.

This means in practice GDB already runs without the custom patches contained
in src/readline/ , just making GDB forked with individual downstream patch fix
ups of the compatibility.

Just the patches are of the kind of MS-related platforms compatibility:
	+dnl BEGIN changes for CYGNUS cross-building for Cygwin
	+#ifdef __MSDOS__
	+#if defined (__GO32__)
	+#ifndef __MINGW32__
	!+#if defined (SIGWINCH)
	? (+#if defined (HAVE_GETPWENT))

Other patches are for rl_prompt and signals where there were enough upstream
readline modifications I do not think these patches are meaningfully
applicable anymore.

Unfortunately there is AFAIK usually (in some cases there is) no testcase of
readline.

Before 7.3 cut off I ask about the opinion on these MS-related platforms
compatibility readline patches, Fedora GNU/Linux runs fine with
readline-6.1-2.fc14 with readline-6.2-2.fc15 soon to be GA and also no
reported problems.


Thanks,
Jan

Re: readline rebase 5.1->6.2?

[Joel Brobecker]

Personally, I'm a little nervous about a readline update so close
to branching...  I'm not opposed to giving it a try, but I think
we should wait for after branching.

-- 
Joel

Re: readline rebase 5.1->6.2?

[Tom Tromey]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> it is a bity pity the sourceware tree still bundles readline-5.1
Jan> while distros build GDB with readline less than 5 years old.

[...]

Jan> Before 7.3 cut off I ask about the opinion on these MS-related platforms
Jan> compatibility readline patches, Fedora GNU/Linux runs fine with
Jan> readline-6.1-2.fc14 with readline-6.2-2.fc15 soon to be GA and also no
Jan> reported problems.

I think upgrading is a good idea, but I think any upgrade should be done
on the trunk after 7.3 branches -- the sooner after the branch is made,
the better.

Tom

Re: readline rebase 5.1->6.2?

[Kai Tietz]

2011/3/22 Jan Kratochvil <jan.kratochvil@redhat.com>:
> Just the patches are of the kind of MS-related platforms compatibility:
>        +dnl BEGIN changes for CYGNUS cross-building for Cygwin
>        +#ifdef __MSDOS__
>        +#if defined (__GO32__)
>        +#ifndef __MINGW32__
>        !+#if defined (SIGWINCH)
>        ? (+#if defined (HAVE_GETPWENT))
>
> Other patches are for rl_prompt and signals where there were enough upstream
> readline modifications I do not think these patches are meaningfully
> applicable anymore.
>
> Unfortunately there is AFAIK usually (in some cases there is) no testcase of
> readline.
>
> Before 7.3 cut off I ask about the opinion on these MS-related platforms
> compatibility readline patches, Fedora GNU/Linux runs fine with
> readline-6.1-2.fc14 with readline-6.2-2.fc15 soon to be GA and also no
> reported problems.

Well, I would also expect that in general those patches aren't
meaningfully applicable anymore. But I think this upgrade should wait
until 7.3 is escaped.

>
> Thanks,
> Jan
>

Kai

Re: readline rebase 5.1->6.2?

[Eli Zaretskii]

> Date: Tue, 22 Mar 2011 16:43:27 +0100
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: Kai Tietz <ktietz@redhat.com>, Eli Zaretskii <eliz@gnu.org>,
>         Christopher Faylor <cgf-use-the-mailinglist-please@gnu.org>
> 
> Just the patches are of the kind of MS-related platforms compatibility:
> 	+dnl BEGIN changes for CYGNUS cross-building for Cygwin
> 	+#ifdef __MSDOS__
> 	+#if defined (__GO32__)
> 	+#ifndef __MINGW32__
> 	!+#if defined (SIGWINCH)
> 	? (+#if defined (HAVE_GETPWENT))

I'm not sure I understand: are you saying that the local patches we
have in GDB wrt the original readline 5.1 are those listed above?  If
so, the last two are not about MS platforms.

> Before 7.3 cut off I ask about the opinion on these MS-related platforms
> compatibility readline patches

Can you show these patches in full?  I'm quite sure the changes
related to __MSDOS__ and __GO32__ are still needed, but I'd like to
review them.  I could also try looking at the __MINGW32__ patches.

Thanks.

Re: readline rebase 5.1->6.2?

[Jan Kratochvil]

On Tue, 22 Mar 2011 20:05:45 +0100, Eli Zaretskii wrote:
> > Just the patches are of the kind of MS-related platforms compatibility:
> > 	+dnl BEGIN changes for CYGNUS cross-building for Cygwin
> > 	+#ifdef __MSDOS__
> > 	+#if defined (__GO32__)
> > 	+#ifndef __MINGW32__
> > 	!+#if defined (SIGWINCH)
> > 	? (+#if defined (HAVE_GETPWENT))
> 
> I'm not sure I understand: are you saying that the local patches we
> have in GDB wrt the original readline 5.1 are those listed above?  If
> so, the last two are not about MS platforms.

The patch for SIGWINCH applies for the case when SIGWINCH is not defined
- which happens only on some non-UNIX platforms I guess, I do not know if on
MS platforms.

With HAVE_GETPWENT you are right that patch may be completely unrelated to the
MS platforms.


> Can you show these patches in full?

I do not have anything else than you have.  I just used diff on
	ftp://ftp.cwru.edu/pub/bash/readline-5.1.tar.gz
vs. src/readline.  But one should rather check individual patches
with git annotate / git show etc. and compare them against readline-6.2.


Thanks,
Jan

Re: readline rebase 5.1->6.2?

[Eli Zaretskii]

> Date: Tue, 22 Mar 2011 20:48:36 +0100
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: gdb@sourceware.org, ktietz@redhat.com,
>         cgf-use-the-mailinglist-please@gnu.org
> 
> I do not have anything else than you have.  I just used diff on
> 	ftp://ftp.cwru.edu/pub/bash/readline-5.1.tar.gz
> vs. src/readline.  But one should rather check individual patches
> with git annotate / git show etc. and compare them against readline-6.2.

OK, I will have a look.

Re: readline rebase 5.1->6.2?

[Tom Tromey]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> I do not have anything else than you have.  I just used diff on
Jan> 	ftp://ftp.cwru.edu/pub/bash/readline-5.1.tar.gz
Jan> vs. src/readline.  But one should rather check individual patches
Jan> with git annotate / git show etc. and compare them against readline-6.2.

I think you can see the full diff of 5.1 -vs- src using:

    cd src/readline
    cvs diff -rreadline_5_1 -rHEAD 

At least, readline_5_1 seems to be the import tag.

Tom

Re: readline rebase 5.1->6.2?

[Joel Brobecker]

> > Can you show these patches in full?
> 
> I do not have anything else than you have.  I just used diff on
> 	ftp://ftp.cwru.edu/pub/bash/readline-5.1.tar.gz
> vs. src/readline.  But one should rather check individual patches
> with git annotate / git show etc. and compare them against readline-6.2.

I think we've been very careful to make sure we get approval
upstream in readline before checking in patches locally.  So
the number of local changes not present upstream should indeed
be very small.

-- 
Joel

Re: readline rebase 5.1->6.2?

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb@sourceware.org, ktietz@redhat.com,
>         cgf-use-the-mailinglist-please@gnu.org
> Date: Tue, 22 Mar 2011 14:03:51 -0600
> 
> I think you can see the full diff of 5.1 -vs- src using:
> 
>     cd src/readline
>     cvs diff -rreadline_5_1 -rHEAD 
> 
> At least, readline_5_1 seems to be the import tag.

Thanks, that was very useful.

Re: readline rebase 5.1->6.2?

[Eli Zaretskii]

> Date: Tue, 22 Mar 2011 21:58:15 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gdb@sourceware.org, ktietz@redhat.com, cgf-use-the-mailinglist-please@gnu.org
> 
> > Date: Tue, 22 Mar 2011 20:48:36 +0100
> > From: Jan Kratochvil <jan.kratochvil@redhat.com>
> > Cc: gdb@sourceware.org, ktietz@redhat.com,
> >         cgf-use-the-mailinglist-please@gnu.org
> > 
> > I do not have anything else than you have.  I just used diff on
> > 	ftp://ftp.cwru.edu/pub/bash/readline-5.1.tar.gz
> > vs. src/readline.  But one should rather check individual patches
> > with git annotate / git show etc. and compare them against readline-6.2.
> 
> OK, I will have a look.

I compared readline-6.2 with our local changes since 5.1, and I see
that the changes below are not in 6.2.  I only paid attention to
DJGPP/MSDOS-specific patches and to MinGW-specific patches, because
Jan seemed to have covered the rest.  (One of the MinGW-specific
patches has a comment saying the underlying problem should be fixed in
readline 5.2, but I don't know what is the problem, so I couldn't
check whether it is indeed fixed.)

The question is, what should we do about these patches?  Submitting
them to upstream readline would be the best course (assuming the
readline maintainer is willing to include them), but that means we
will have to either wait for the next readline release or keep our
local patches for the time being.

--- display.c	20 Apr 2006 20:05:36 -0000	1.1.1.7
+++ display.c	24 Mar 2008 12:59:51 -0000	1.12
@@ -41,6 +41,10 @@
 
 #include <stdio.h>
 
+#ifdef __MSDOS__
+# include <pc.h>
+#endif
+
 /* System-specific feature definitions and include files. */
 #include "rldefs.h"
 #include "rlmbutil.h"
@@ -1782,9 +1792,18 @@ _rl_move_vert (to)
     }
   else
     {			/* delta < 0 */
+#ifdef __MSDOS__
+      int row, col;
+
+      fflush (rl_outstream); /* make sure the cursor pos is current! */
+      ScreenGetCursor (&row, &col);
+      ScreenSetCursor (row + delta, col);
+      i = -delta;    /* in case someone wants to use it after the loop */
+#else /* !__MSDOS__ */
       if (_rl_term_up && *_rl_term_up)
 	for (i = 0; i < -delta; i++)
 	  tputs (_rl_term_up, 1, _rl_output_character_function);
+#endif /* !__MSDOS__ */
     }
 
   _rl_last_v_pos = to;		/* Now TO is here */
@@ -2036,9 +2057,12 @@ void
 _rl_clear_to_eol (count)
      int count;
 {
+#ifndef __MSDOS__
   if (_rl_term_clreol)
     tputs (_rl_term_clreol, 1, _rl_output_character_function);
-  else if (count)
+  else
+#endif
+  if (count)
     space_to_eol (count);
 }
 
@@ -2059,10 +2083,15 @@ space_to_eol (count)
 void
 _rl_clear_screen ()
 {
+#if defined (__GO32__)
+  ScreenClear ();	/* FIXME: only works in text modes */
+  ScreenSetCursor (0, 0);  /* term_clrpag is "cl" which homes the cursor */
+#else
   if (_rl_term_clrpag)
     tputs (_rl_term_clrpag, 1, _rl_output_character_function);
   else
     rl_crlf ();
+#endif
 }
 
 /* Insert COUNT characters from STRING to the output stream at column COL. */


--- emacs_keymap.c	23 Aug 2002 22:02:28 -0000	1.1.1.3
+++ emacs_keymap.c	5 May 2006 18:26:12 -0000	1.6
@@ -278,7 +278,13 @@ KEYMAP_ENTRY_ARRAY emacs_standard_keymap
   { ISFUNC, rl_insert },	/* Latin capital letter Y with acute */
   { ISFUNC, rl_insert },	/* Latin capital letter thorn (Icelandic) */
   { ISFUNC, rl_insert },	/* Latin small letter sharp s (German) */
+#ifndef __MINGW32__
   { ISFUNC, rl_insert },	/* Latin small letter a with grave */
+#else
+  /* Temporary - this is a bug in readline 5.1 that should be fixed in
+     readline 5.2.  */
+  { ISFUNC, 0 },		/* Must leave this unbound for the arrow keys to work.  */
+#endif
   { ISFUNC, rl_insert },	/* Latin small letter a with acute */
   { ISFUNC, rl_insert },	/* Latin small letter a with circumflex */
   { ISFUNC, rl_insert },	/* Latin small letter a with tilde */


--- terminal.c	20 Apr 2006 20:05:37 -0000	1.1.1.7
+++ terminal.c	13 Nov 2006 09:33:30 -0000	1.11
@@ -55,6 +55,10 @@
 #  include <sys/ioctl.h>
 #endif /* GWINSZ_IN_SYS_IOCTL && !TIOCGWINSZ */
 
+#ifdef __MSDOS__
+# include <pc.h>
+#endif
+
 #include "rltty.h"
 #include "tcap.h"
 
@@ -66,6 +70,11 @@
 #include "rlshell.h"
 #include "xmalloc.h"
 
+#if defined (__MINGW32__)
+# include <windows.h>
+# include <wincon.h>
+#endif
+
 #define CUSTOM_REDISPLAY_FUNC() (rl_redisplay_function != rl_redisplay)
 #define CUSTOM_INPUT_FUNC() (rl_getc_function != rl_getc)
 
@@ -77,8 +86,10 @@ int rl_prefer_env_winsize;
 /*								    */
 /* **************************************************************** */
 
+#ifndef __MSDOS__
 static char *term_buffer = (char *)NULL;
 static char *term_string_buffer = (char *)NULL;
+#endif /* !__MSDOS__ */
 
 static int tcap_initialized;
 
@@ -207,6 +218,20 @@ _rl_get_screen_size (tty, ignore_env)
     }
 #endif /* TIOCGWINSZ */
 
+  /* For MinGW, we get the console size from the Windows API.  */
+#if defined (__MINGW32__)
+  HANDLE hConOut = GetStdHandle (STD_OUTPUT_HANDLE);
+  if (hConOut != INVALID_HANDLE_VALUE)
+    {
+      CONSOLE_SCREEN_BUFFER_INFO scr;
+      if (GetConsoleScreenBufferInfo (hConOut, &scr))
+	{
+	  wc = scr.dwSize.X;
+	  wr = scr.srWindow.Bottom - scr.srWindow.Top + 1;
+	}
+    }
+#endif
+
 #if defined (__EMX__)
   _emx_get_screensize (&_rl_screenwidth, &_rl_screenheight);
 #endif
@@ -230,7 +255,10 @@ _rl_get_screen_size (tty, ignore_env)
       if (_rl_screenwidth <= 0)
         _rl_screenwidth = wc;
 
-#if !defined (__DJGPP__)
+#if defined (__DJGPP__)
+      if (_rl_screenwidth <= 0)
+	_rl_screenwidth = ScreenCols ();
+#else
       if (_rl_screenwidth <= 0 && term_string_buffer)
 	_rl_screenwidth = tgetnum ("co");
 #endif
@@ -246,7 +274,10 @@ _rl_get_screen_size (tty, ignore_env)
       if (_rl_screenheight <= 0)
         _rl_screenheight = wr;
 
-#if !defined (__DJGPP__)
+#if defined (__DJGPP__)
+      if (_rl_screenheight <= 0)
+	_rl_screenheight = ScreenRows ();
+#else
       if (_rl_screenheight <= 0 && term_string_buffer)
 	_rl_screenheight = tgetnum ("li");
 #endif
@@ -397,6 +431,23 @@ _rl_init_terminal_io (terminal_name)
   if (term == 0)
     term = "dumb";
 
+#ifdef __MSDOS__
+  _rl_term_im = _rl_term_ei = _rl_term_ic = _rl_term_IC = (char *)NULL;
+  _rl_term_up = _rl_term_dc = _rl_term_DC = _rl_visible_bell = (char *)NULL;
+  _rl_term_ku = _rl_term_kd = _rl_term_kl = _rl_term_kr = (char *)NULL;
+  _rl_term_mm = _rl_term_mo = (char *)NULL;
+  _rl_terminal_can_insert = term_has_meta = _rl_term_autowrap = 0;
+  _rl_term_cr = "\r";
+  _rl_term_clreol = _rl_term_clrpag = _rl_term_backspace = (char *)NULL;
+  _rl_term_goto = _rl_term_pc = _rl_term_ip = (char *)NULL;
+  _rl_term_ks = _rl_term_ke =_rl_term_vs = _rl_term_ve = (char *)NULL;
+  _rl_term_kh = _rl_term_kH = _rl_term_at7 = _rl_term_kI = (char *)NULL;
+#if defined(HACK_TERMCAP_MOTION)
+  _rl_term_forward_char = (char *)NULL;
+#endif
+
+  _rl_get_screen_size (tty, 0);
+#else  /* !__MSDOS__ */
   /* I've separated this out for later work on not calling tgetent at all
      if the calling application has supplied a custom redisplay function,
      (and possibly if the application has supplied a custom input function). */
@@ -499,6 +550,8 @@ _rl_init_terminal_io (terminal_name)
   if (!term_has_meta)
     _rl_term_mm = _rl_term_mo = (char *)NULL;
 
+#endif /* !__MSDOS__ */
+
   /* Attempt to find and bind the arrow keys.  Do not override already
      bound keys in an overzealous attempt, however. */
 
@@ -595,10 +648,12 @@ _rl_backspace (count)
 {
   register int i;
 
+#ifndef __MSDOS__
   if (_rl_term_backspace)
     for (i = 0; i < count; i++)
       tputs (_rl_term_backspace, 1, _rl_output_character_function);
   else
+#endif
     for (i = 0; i < count; i++)
       putc ('\b', _rl_out_stream);
   return 0;
@@ -628,12 +683,17 @@ rl_ding ()
 	default:
 	  break;
 	case VISIBLE_BELL:
+#ifdef __MSDOS__
+	  ScreenVisualBell ();
+	  break;
+#else
 	  if (_rl_visible_bell)
 	    {
 	      tputs (_rl_visible_bell, 1, _rl_output_character_function);
 	      break;
 	    }
 	  /* FALLTHROUGH */
+#endif
 	case AUDIBLE_BELL:
 	  fprintf (stderr, "\007");
 	  fflush (stderr);
@@ -685,6 +745,7 @@ void
 _rl_set_cursor (im, force)
      int im, force;
 {
+#ifndef __MSDOS__
   if (_rl_term_ve && _rl_term_vs)
     {
       if (force || im != rl_insert_mode)
@@ -695,4 +756,5 @@ _rl_set_cursor (im, force)
 	    tputs (_rl_term_ve, 1, _rl_output_character_function);
 	}
     }
+#endif
 }

Re: readline rebase 5.1->6.2?

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> I compared readline-6.2 with our local changes since 5.1, and I see
Eli> that the changes below are not in 6.2.  I only paid attention to
Eli> DJGPP/MSDOS-specific patches and to MinGW-specific patches, because
Eli> Jan seemed to have covered the rest.  (One of the MinGW-specific
Eli> patches has a comment saying the underlying problem should be fixed in
Eli> readline 5.2, but I don't know what is the problem, so I couldn't
Eli> check whether it is indeed fixed.)

Eli> The question is, what should we do about these patches?  Submitting
Eli> them to upstream readline would be the best course (assuming the
Eli> readline maintainer is willing to include them), but that means we
Eli> will have to either wait for the next readline release or keep our
Eli> local patches for the time being.

Yes, submit them.  It is ok if it takes a while for the new readline to
reach our tree.  The result can't be worse than our current situation.

We don't necessarily have to wait for the upstream maintainer to do a
new release.  If he accepts the patches we can import 6.2 and keep them,
to be deleted when we import the subsequent release.

Tom

Re: readline rebase 5.1->6.2?

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: jan.kratochvil@redhat.com, gdb@sourceware.org, ktietz@redhat.com
> Date: Fri, 01 Apr 2011 08:19:32 -0600
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Eli> The question is, what should we do about these patches?  Submitting
> Eli> them to upstream readline would be the best course (assuming the
> Eli> readline maintainer is willing to include them), but that means we
> Eli> will have to either wait for the next readline release or keep our
> Eli> local patches for the time being.
> 
> Yes, submit them.  It is ok if it takes a while for the new readline to
> reach our tree.  The result can't be worse than our current situation.

I sent a private mail to the readline maintainer with the patches.
Let's see what he replies, and take it from there.

Re: readline rebase 5.1->6.2?

[Jan Kratochvil]

On Fri, 01 Apr 2011 11:30:03 +0200, Eli Zaretskii wrote:
> I only paid attention to DJGPP/MSDOS-specific patches and to MinGW-specific
> patches, because Jan seemed to have covered the rest.

I hadn't yet, I have done so now.  I have checked the remaining changes and
these (mostly minor) patches should be applied on top of readline-6.2:
	[Bug-readline] [RFC/readline] bind.c, rl_function_dumper, Free allocated
	http://lists.gnu.org/archive/html/bug-readline/2011-03/msg00000.html
	[Bug-readline] Unused support/wcwidth.c
	http://lists.gnu.org/archive/html/bug-readline/2011-04/msg00000.html
	[Bug-readline] [patch] Fix underquotation in readline/examples/rlfe/conf
	http://lists.gnu.org/archive/html/bug-readline/2011-04/msg00001.html
	[Bug-readline] [patch] Makefile.in htm<->html
	http://lists.gnu.org/archive/html/bug-readline/2011-04/msg00002.html
	Re: [Bug-readline] [patch] Makefile.in dependency: callback.o: xmalloc.h
	http://lists.gnu.org/archive/html/bug-readline/2011-04/msg00004.html
	[Bug-readline] [patch] Remove . from the VPATH directive
	http://lists.gnu.org/archive/html/bug-readline/2011-04/msg00005.html

Together with the sourceware-specific changes which are not suitable for
upstream readline, provided below.  And together with the changes as found by
Eli.

So I believe it is ready for a rebase after the 7.3 branching.

I haven't commented here the diff parts which I have found already present in
readline-6.2, I can do so upon request.  The 5.1patched -> 6.2 change should
be done probably by a single commit - and not as 6.2 pristine + the several
changes below - as otherwise there would be a local build regression which
complicates git bisect.


Thanks,
Jan


This ChangeLog should not go anywhere, these entries are already present in
readline/ChangeLog.gdb.

commit fe454715791b86ad488b33c1f325478803c8108c - import gdb-19990422 snapshot
1999-04-22  Jason Molenda  <jsm@bugshack.cygnus.com>

	* Makefile.in (install): Make comment about this change more explicit.

1999-04-22  Jason Molenda  <jsm@bugshack.cygnus.com>

	* Makefile.in (install): Don't install the final libreadline.a
	or .h files.

commit 47add2a0e5b7e970014e000ac1a3a1cc42c31798
2009-08-22  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* configure.in: m4_include toplevel config/override.m4.
	* configure: Regenerate.

commit 14cd51f7793a9ce07bc435069f57269450141363 - Initial revision
 - unaware where that AC_CONFIG_AUX_DIR change came from.

commit 1809460e45c24a51bcbac82243cad09117cd43c5
2002-12-16  Christopher Faylor  <cgf@redhat.com>

	* configure.in: Remove --enable-shared option.  It shouldn't be used
	for gdb.
	* configure: Regenerate.

commit 14cd51f7793a9ce07bc435069f57269450141363 - Initial revision
Tue Dec 29 18:11:28 1998  Elena Zannoni  <ezannoni@kwikemart.cygnus.com>

	* cross-build/cygwin.cache: new file. Used for Cygwin cross builds.

--- readline-6.2-orig/Makefile.in	2010-10-11 17:53:52.000000000 +0200
+++ readline-6.2/Makefile.in	2011-04-02 21:22:36.000000000 +0200
@@ -211,7 +211,17 @@ examples: force
 
 force:
 
-install:	$(INSTALL_TARGETS)
+## GDB LOCAL
+## Don't mess with people's installed readline's.
+## This tries to install this version of readline over whatever
+## version is already installed on the system (which could be a
+## newer version). There is no real reason for us to install
+## readline along with GDB. GDB links statically against readline,
+## so it doesn't depend on us installing it on the system.
+
+install:
+
+#install:	$(INSTALL_TARGETS)
 
 install-headers: installdirs ${INSTALLED_HEADERS}
 	for f in ${INSTALLED_HEADERS}; do \
--- readline-6.2-orig/examples/rlfe/configure.in	2006-11-09 16:51:12.000000000 +0100
+++ readline-6.2/examples/rlfe/configure.in	2011-04-02 21:22:36.000000000 +0200
@@ -1,5 +1,7 @@
 dnl Process this file with autoconf to produce a configure script.
 
+m4_include([../../../config/override.m4])
+
 AC_INIT(rlfe.c)
 AC_CONFIG_HEADER(config.h)
 VERSION=0.4
--- readline-6.2-orig/configure.in	2010-11-14 23:41:48.000000000 +0100
+++ readline-6.2/configure.in	2011-04-02 21:23:07.000000000 +0200
@@ -22,13 +22,17 @@ dnl Process this file with autoconf to p
 
 AC_REVISION([for Readline 6.2, version 2.67])
 
+m4_include([../config/override.m4])
+
 AC_INIT(readline, 6.2, bug-readline@gnu.org)
 
 dnl make sure we are using a recent autoconf version
 AC_PREREQ(2.50)
 
 AC_CONFIG_SRCDIR(readline.h)
-AC_CONFIG_AUX_DIR(./support)
+dnl GDB LOCAL
+dnl AC_CONFIG_AUX_DIR(./support)
+AC_CONFIG_AUX_DIR(`cd $srcdir;pwd`/..)
 AC_CONFIG_HEADERS(config.h)
 
 dnl update the value of RL_READLINE_VERSION in readline.h when this changes
@@ -57,10 +61,10 @@ fi
 dnl option parsing for optional features
 opt_multibyte=yes
 opt_static_libs=yes
-opt_shared_libs=yes
+opt_shared_libs=no
 
 AC_ARG_ENABLE(multibyte, AC_HELP_STRING([--enable-multibyte], [enable multibyte characters if OS supports them]), opt_multibyte=$enableval)
-AC_ARG_ENABLE(shared, AC_HELP_STRING([--enable-shared], [build shared libraries [[default=YES]]]), opt_shared_libs=$enableval)
+dnl AC_ARG_ENABLE(shared, AC_HELP_STRING([--enable-shared], [build shared libraries [[default=YES]]]), opt_shared_libs=$enableval)
 AC_ARG_ENABLE(static, AC_HELP_STRING([--enable-static], [build static libraries [[default=YES]]]), opt_static_libs=$enableval)
 
 if test $opt_multibyte = no; then
--- readline-6.2-orig/cross-build/cygwin.cache	1970-01-01 01:00:00.000000000 +0100
+++ readline-6.2/cross-build/cygwin.cache	2011-04-02 21:22:36.000000000 +0200
@@ -0,0 +1,46 @@
+# This file is a shell script that caches the results of configure
+# tests for CYGWIN32 so they don't need to be done when cross-compiling.
+
+# AC_FUNC_GETPGRP should also define GETPGRP_VOID
+ac_cv_func_getpgrp_void=${ac_cv_func_getpgrp_void='yes'}
+# AC_FUNC_SETVBUF_REVERSED should not define anything else
+ac_cv_func_setvbuf_reversed=${ac_cv_func_setvbuf_reversed='no'}
+# on CYGWIN32, system calls do not restart
+ac_cv_sys_restartable_syscalls=${ac_cv_sys_restartable_syscalls='no'}
+bash_cv_sys_restartable_syscalls=${bash_cv_sys_restartable_syscalls='no'}
+
+# these may be necessary, but they are currently commented out
+#ac_cv_c_bigendian=${ac_cv_c_bigendian='no'}
+ac_cv_sizeof_char_p=${ac_cv_sizeof_char_p='4'}
+ac_cv_sizeof_int=${ac_cv_sizeof_int='4'}
+ac_cv_sizeof_long=${ac_cv_sizeof_long='4'}
+
+bash_cv_dup2_broken=${bash_cv_dup2_broken='no'}
+bash_cv_pgrp_pipe=${bash_cv_pgrp_pipe='no'}
+bash_cv_type_rlimit=${bash_cv_type_rlimit='long'}
+bash_cv_decl_under_sys_siglist=${bash_cv_decl_under_sys_siglist='no'}
+bash_cv_under_sys_siglist=${bash_cv_under_sys_siglist='no'}
+bash_cv_sys_siglist=${bash_cv_sys_siglist='no'}
+bash_cv_opendir_not_robust=${bash_cv_opendir_not_robust='no'}
+bash_cv_getenv_redef=${bash_cv_getenv_redef='yes'}
+bash_cv_printf_declared=${bash_cv_printf_declared='yes'}
+bash_cv_ulimit_maxfds=${bash_cv_ulimit_maxfds='no'}
+bash_cv_getcwd_calls_popen=${bash_cv_getcwd_calls_popen='no'}
+bash_cv_must_reinstall_sighandlers=${bash_cv_must_reinstall_sighandlers='no'}
+bash_cv_job_control_missing=${bash_cv_job_control_missing='present'}
+bash_cv_sys_named_pipes=${bash_cv_sys_named_pipes='missing'}
+bash_cv_func_sigsetjmp=${bash_cv_func_sigsetjmp='present'}
+bash_cv_mail_dir=${bash_cv_mail_dir='unknown'}
+bash_cv_func_strcoll_broken=${bash_cv_func_strcoll_broken='no'}
+bash_cv_have_mbstate_t=${bash_cv_have_mbstate_t='yes'}
+
+bash_cv_type_int32_t=${bash_cv_type_int32_t='int'}
+bash_cv_type_u_int32_t=${bash_cv_type_u_int32_t='int'}
+ac_cv_header_termcap_h=${ac_cv_header_termcap_h='yes'}
+ac_cv_header_termios_h=${ac_cv_header_termios_h='yes'}
+bash_cv_termcap_lib=${bash_cv_termcap_lib='-ltermcap'}
+
+bash_cv_tiocgwinsz_in_ioctl=${bash_cv_tiocgwinsz_in_ioctl='yes'}
+ac_cv_lib_termcap_tgetent=${ac_cv_lib_termcap_tgetent='yes'}
+
+# end of cross-build/cygwin32.cache

Re: readline rebase 5.1->6.2?

[Eli Zaretskii]

> Date: Sat, 02 Apr 2011 13:29:45 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: jan.kratochvil@redhat.com, gdb@sourceware.org, ktietz@redhat.com
> 
> > From: Tom Tromey <tromey@redhat.com>
> > Cc: jan.kratochvil@redhat.com, gdb@sourceware.org, ktietz@redhat.com
> > Date: Fri, 01 Apr 2011 08:19:32 -0600
> > 
> > >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > Eli> The question is, what should we do about these patches?  Submitting
> > Eli> them to upstream readline would be the best course (assuming the
> > Eli> readline maintainer is willing to include them), but that means we
> > Eli> will have to either wait for the next readline release or keep our
> > Eli> local patches for the time being.
> > 
> > Yes, submit them.  It is ok if it takes a while for the new readline to
> > reach our tree.  The result can't be worse than our current situation.
> 
> I sent a private mail to the readline maintainer with the patches.
> Let's see what he replies, and take it from there.

Chet agreed:

> Sure, I'll look at applying the patches.  They'll be in the next readline
> release.

So we can now act on the assumption that the DJGPP-related patches to
readline are no longer an issue.

Note that I didn't do anything about the MinGW patches.  I suggest
that their author(s) submit them to readline.

Re: readline rebase 5.1->6.2?

[Jan Kratochvil]

On Sun, 03 Apr 2011 05:00:55 +0200, Eli Zaretskii wrote:
> Note that I didn't do anything about the MinGW patches.  I suggest
> that their author(s) submit them to readline.

The only one I found is attached, it is already present in readline-6.2-001.
The configure.in part `*-mingw*)' is also present there.

Therefore I believe we can now rebase readline to 6.2-001 for gdb-7.4, I will
send some patch for test into gdb-patches.


Thanks,
Jan


--- readline-5.1-004/input.c	2005-07-05 04:30:24.000000000 +0200
+++ ./input.c	2011-04-02 10:43:16.000000000 +0200
@@ -220,6 +220,16 @@ rl_gather_tyi ()
     }
 #endif /* O_NDELAY */
 
+#if defined (__MINGW32__)
+  /* We use getch to read console input, so use the same
+     mechanism to check for more.  Otherwise, we don't know.  */
+  if (isatty (fileno (rl_instream)))
+    chars_avail = _kbhit ();
+  else
+    chars_avail = 0;
+  result = 0;
+#endif
+
   /* If there's nothing available, don't waste time trying to read
      something. */
   if (chars_avail <= 0)
@@ -305,6 +315,13 @@ _rl_input_available ()
 
 #endif
 
+#if defined (__MINGW32__)
+  /* We use getch to read console input, so use the same
+     mechanism to check for more.  Otherwise, we don't know.  */
+  if (isatty (fileno (rl_instream)))
+    return _kbhit ();
+#endif
+
   return 0;
 }