Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Richard Haney <rfhaney@yahoo.com>
To: gdb@sources.redhat.com
Cc: Christopher Faylor <cgf-gdb@sources.redhat.com>
Subject: Re: Need for libreadline.a from a gdb package compatible with gcc 2.95.2
Date: Thu, 02 Jan 2003 20:29:00 -0000	[thread overview]
Message-ID: <20030102202911.40504.qmail@web11602.mail.yahoo.com> (raw)

[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


             reply	other threads:[~2003-01-02 20:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-02 20:29 Richard Haney [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-12-15 16:46 Richard Haney
2002-12-15 17:02 ` Christopher Faylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030102202911.40504.qmail@web11602.mail.yahoo.com \
    --to=rfhaney@yahoo.com \
    --cc=cgf-gdb@sources.redhat.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox