Need for libreadline.a from a gdb package compatible with gcc 2.95.2

Need for libreadline.a from a gdb package compatible with gcc 2.95.2

[Richard Haney]

I have recently downloaded a gdb package (gdb-5.2.1-20021009.tar.gz)
from <www.mingw.org>.  The package contains a gcc 3.2 compatible copy
of libreadline.a for the win32 (MinGW, i.e., non-cygwin) environment. 
That library works fine with gcc 3.2.  But I need to build packages
using gcc 2.95.2, and gcc 2.95.2 does not link its output modules to
gcc 3.2 output modules.  So apparently, I can't use the libreadline.a
from the above gdb package for my gcc 2.95.2 builds.

I've also tried building libreadline using gcc 2.95.2, but the build
package assumes that my environment is one of three types, two of which
involve the use of 'termio.h' and/or 'termios.h'.  But my computing
enviroment is none of the three.

Is there an "old" gdb package around somewhere that has a libreadline.a
compiled with gcc 2.95.2 for win32 (preferably, MinGW, non-cygwin)?

Richard Haney


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: Need for libreadline.a from a gdb package compatible with gcc 2.95.2

[Christopher Faylor]

[Reply-To set to list]
On Sun, Dec 15, 2002 at 04:46:51PM -0800, Richard Haney wrote:
>I have recently downloaded a gdb package (gdb-5.2.1-20021009.tar.gz)
>from <www.mingw.org>.  The package contains a gcc 3.2 compatible copy
>of libreadline.a for the win32 (MinGW, i.e., non-cygwin) environment. 
>That library works fine with gcc 3.2.  But I need to build packages
>using gcc 2.95.2, and gcc 2.95.2 does not link its output modules to
>gcc 3.2 output modules.  So apparently, I can't use the libreadline.a
>from the above gdb package for my gcc 2.95.2 builds.
>
>I've also tried building libreadline using gcc 2.95.2, but the build
>package assumes that my environment is one of three types, two of which
>involve the use of 'termio.h' and/or 'termios.h'.  But my computing
>enviroment is none of the three.
>
>Is there an "old" gdb package around somewhere that has a libreadline.a
>compiled with gcc 2.95.2 for win32 (preferably, MinGW, non-cygwin)?

The MinGW version of gdb is maintained by MinGW volunteers.  It is not
an official version of gdb.  If you are having problems with it or have
questions about it you should direct them to the MinGW mailing list.

cgf

Re: Need for libreadline.a from a gdb package compatible with gcc 2.95.2

[Richard Haney]

[Reply-To set to list]
> On Sun, 15 Dec 2002 20:04:14 -0500, Christopher Faylor wrote:
> The MinGW version of gdb is maintained by MinGW volunteers.  It is
not
> an official version of gdb.  If you are having problems with it or
have
> questions about it you should direct them to the MinGW mailing list. 

One of the alternative approaches to solving my problem is 
to actually build libreadline.a (and libhistory.a) from the 
readline build package (vers. 4.3) using gcc 2.95.2.

I've tried this several times with numerous variations, 
including mixes with ad hoc adaptations from cygwin headers. 

The most durable and seemingly 'unsolvable' problem seems to 
be the fact that the readline build package assumes that my 
computing environment must be one of three types as far as 
terminal io and tty are concerned.  (When I ran ./configure, 
the configured files resulted in the macro NEW_TTY_DRIVER being 
defined, thus assuming that my computing environment had to 
have 'sgtty.h'.) 

Here is my analysis and the code that seems to embody the 
critical assumptions in this regard: 

Analysis:

Readline build header rltty.h wants to include sgtty.h 
because NEW_TTY_DRIVER is defined.  But there is no sgtty.h 
(except in the cygwin headers, but gcc 2.95.2 seems to be 
incompatible with the cygwin libraries). 

Readline build header rldefs.h is the only place where 
NEW_TTY_DRIVER is defined and defines it as follows: 

#if defined (_POSIX_VERSION) && !defined (TERMIOS_MISSING)
#  define TERMIOS_TTY_DRIVER
#else
#  if defined (HAVE_TERMIO_H)
#    define TERMIO_TTY_DRIVER
#  else
#    define NEW_TTY_DRIVER
#  endif
#endif


[###] So evidently we need to have _POSIX_VERSION defined 
and TERMIOS_MISSING not defined; or failing that we need to 
have HAVE_TERMIO_H defined. 

[###] No file in the main directory defines 
"_POSIX_VERSION". 

config.h is the only file that defines TERMIOS_MISSING, and 
it does so conditionally as follows: 

#if !defined (HAVE_TERMIOS_H) || !defined (HAVE_TCGETATTR) || defined
(ultrix)
#  define TERMIOS_MISSING
#endif

Thus TERMIOS_MISSING is defined iff (HAVE_TERMIOS_H is not 
defined or HAVE_TCGETATTR is not defined) or "ultrix" is 
defined.  Thus, for TERMIOS_MISSING to be not defined we 
need to have both HAVE_TERMIOS_H and HAVE_TCGETATTR defined 
and "ultrix" not defined. 

[###] In summary, we need both HAVE_TERMIOS_H and 
HAVE_TCGETATTR defined and "ultrix" not defined; and, as 
first noted, we need _POSIX_VERSION defined as well; or 
failing any of these requirements we need HAVE_TERMIO_H 
defined.  (Note the 'S' difference between 'HAVE_TERMIOS_H' 
and 'HAVE_TERMIO_H'.) 

Is there some work-around or or adaptation I can create in 
my environment so that I can build libreadline.a (and 
libhistory.a)?

Note that the MinGW version of libreadline.a seems to work 
just fine when I use gcc 3.2.  So my environment is capable 
of running programs using 'libreadline.a'.  And I don't need 
sgtty.h or cygwin for that.  The problem seems to be how to 
tell the readline build package what it needs to know about 
my environment in order to build its libraries successfully. 

Richard Haney


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com