From: Michael Elizabeth Chastain <mec@shout.net>
To: ac131313@redhat.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [rfa] PROBLEMS (i[3456]86-*-linux*): Require glibc 2.1.3 or later
Date: Tue, 25 Feb 2003 17:10:00 -0000 [thread overview]
Message-ID: <200302251710.h1PHAhv07449@duracef.shout.net> (raw)
> Should the build notes also mention this? The PROBLEM (groan) with the
> PROBLEMS file is that people often don't read it :-).
I picked PROBLEMS because it seemed to be the file with the
appropriate level of detail.
I'm flexible on this, I'm willing to wrote notes wherever you like, just
say where. Do you want text in 'README: Unpacking and Installation:
Quick Overview' or 'NEWS', or ???
> Does the build (configure or compile) barf clearly explain the reason
> for the failure? If it is this common, GDB might as well be a little
> proactive and complain up front.
The compile barfs like this:
In file included from ../../gdb-5.2/gdb/thread-db.c:26:
../../gdb-5.2/gdb/gdb_thread_db.h:211: parse error before `uintptr_t'
../../gdb-5.2/gdb/gdb_thread_db.h:211: warning: no semicolon at end
of struct or union
../../gdb-5.2/gdb/gdb_thread_db.h:211: warning: no semicolon at end
of struct or union
../../gdb-5.2/gdb/gdb_thread_db.h:212: warning: type defaults to
`int' in declaration of `msg'
../../gdb-5.2/gdb/gdb_thread_db.h:212: warning: data definition has
no type or storage class
../../gdb-5.2/gdb/gdb_thread_db.h:213: parse error before `}'
This could be detected at autoconf time, something like:
AC_MSG_CHECKING(for uintptr_t support in glibc)
AC_CACHE_VAL(ac_cv_c_uintptr_t,
[AC_TRY_COMPILE(, [
#include <stdint.h>
uintptr_t foo;
],
ac_cv_c_uintptr_t=yes, ac_cv_c_uintptr_t=no)])
AC_MSG_RESULT($ac_cv_c_uintptr_t)
if test $ac_cv_c_uintptr_t = yes; then
AC_DEFINE(HAVE_UINTPTR_T)
fi
Then gdb_thread_db.h could produce a better error message if it
gets compiled. It's used only on *-*-*linux* and s390-*-*,
not everywhere.
Do you want to go in that direction? That looks reasonable to me.
I would balk at actually filling in a defintion of uintptr_t though.
If their glibc is that old (3 years old!) they are likely to have
other problems and I want to cauterize their build.
Michael C
next reply other threads:[~2003-02-25 17:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-25 17:10 Michael Elizabeth Chastain [this message]
2003-02-25 18:10 ` Joel Brobecker
2003-02-25 19:43 ` Andrew Cagney
-- strict thread matches above, loose matches on Subject: below --
2003-02-25 22:01 Michael Elizabeth Chastain
2003-02-25 20:08 Michael Elizabeth Chastain
2003-02-25 18:13 Michael Elizabeth Chastain
2003-02-25 15:49 Michael Elizabeth Chastain
2003-02-25 16:33 ` Andrew Cagney
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=200302251710.h1PHAhv07449@duracef.shout.net \
--to=mec@shout.net \
--cc=ac131313@redhat.com \
--cc=gdb-patches@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