Re: [rfa] PROBLEMS (i[3456]86-*-linux*): Require glibc 2.1.3 or later

Re: [rfa] PROBLEMS (i[3456]86-*-linux*): Require glibc 2.1.3 or later

[Michael Elizabeth Chastain]

Joel B asks:

> Why not even fail at autoconf time?

Because configure does not know which hosts need uintptr_t.

Meanwhile, I would like to get approval (or rejection) on my
proposed addition to PROBLEMS.  Even if we add autoconf stuff
for this, I think we still need a note in PROBLEMS about it.

Michael C

Re: [rfa] PROBLEMS (i[3456]86-*-linux*): Require glibc 2.1.3 or later

[Michael Elizabeth Chastain]

Committed, after private approval from Andrew C.

I am working on a followup patch to teach 'configure' about uintptr_t,
and then I can make gdb_threads.h emit a more informative error
message.

One PR part-way down.  640 more after that.

Michael C

===

2003-02-25  Michael Chastain  <mec@shout.net>

	* PROBLEMS (i[3456]86-*-linux*): Require glibc 2.1.3 or later
	to avoid uintptr_t definition problems.

Re: [rfa] PROBLEMS (i[3456]86-*-linux*): Require glibc 2.1.3 or later

[Michael Elizabeth Chastain]

Andrew C says:

  I think this is the best option.  And, say have gdb_thread_db.h have:

  #ifndef HAVE_UINTPTR_T
  #error "..... (your glibc is too old?)"
  #endif

Sounds good to me.  I'll go write my first configure.in patch!

Michael C

Re: [rfa] PROBLEMS (i[3456]86-*-linux*): Require glibc 2.1.3 or later

[Michael Elizabeth Chastain]

> 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

Re: [rfa] PROBLEMS (i[3456]86-*-linux*): Require glibc 2.1.3 or later

[Joel Brobecker]

> 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.

Why not even fail at autoconf time?

-- 
Joel

Re: [rfa] PROBLEMS (i[3456]86-*-linux*): Require glibc 2.1.3 or later

[Andrew Cagney]

> 
> 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

I think this is the best option.  And, say have gdb_thread_db.h have:

#ifndef HAVE_UINTPTR_T
#error "..... (your glibc is too old?)"
#endif

Andrew


> 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
> 

[rfa] PROBLEMS (i[3456]86-*-linux*): Require glibc 2.1.3 or later

[Michael Elizabeth Chastain]

This patch documents a problem when building gdb with old libc or glibc.
The problem is a missing definition of 'uintptr_t'.  This is PR gdb/660,
and I have also seen this problem reported on bug-gdb.  We have so many
users that we see amazing version skew in the field.

I don't think we should fix this problem; I would rather just add a
requirement that people upgrade their glibc (or their libc5).  Then we
can point to the requirement in the PROBLEMS file and close PR's.

If somebody (perhaps the thread people) says that we need to jack up
the requirement from 2.1.3 to whatever, I'm open to that.  I just want
to document an actual requirement.

Testing: I haven't actually built with glibc 2.1.3, but I did check
the glibc source code and found the 'uintptr_t' definition in there.

OK to commit?

Michael C

2003-02-25  Michael Chastain  <mec@shout.net>

	* PROBLEMS (i[3456]86-*-linux*): Require glibc 2.1.3 or later
	to avoid uintptr_t definition problems.

Index: PROBLEMS
===================================================================
RCS file: /cvs/src/src/gdb/PROBLEMS,v
retrieving revision 1.12
diff -u -r1.12 PROBLEMS
--- PROBLEMS	5 Feb 2003 17:45:14 -0000	1.12
+++ PROBLEMS	25 Feb 2003 15:40:19 -0000
@@ -69,6 +69,10 @@
 i[3456]86-*-linux*
 ------------------
 
+gdb/660: gdb does not build with linux libc5.  The symptom is a parse
+error before `uintptr_t'.  Upgrade to glibc 2.1.3 or later, which
+defines uintptr_t.
+
 gdb/1030: GNU binutils 2.12.1 and earlier versions do not work properly
 with gdb.  If you use GNU binutils, upgrade to version 2.13 or later.
 You can check the version of binutils with the command:

Re: [rfa] PROBLEMS (i[3456]86-*-linux*): Require glibc 2.1.3 or later

[Andrew Cagney]

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.

Should the build notes also mention this?  The PROBLEM (groan) with the 
PROBLEMS file is that people often don't read it :-).

Andrew