This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Fix compilation failure of remote-fileio.c


> Date: Tue, 30 Dec 2003 03:26:25 -0500 (EST)
> From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
> 
>   ftp://sources.redhat.com/pub/binutils/autoconf-000227.tar.bz2
> 
> This version of autoconf identifies itself as "autoconf version 2.13",
> but produces different "configure" files than autoconf 2.13.
> Fun fun fun!

Indeed!

Thanks for the pointer, I will fetch that.

> I would recommend:
> 
>   -- download autoconf 000227
>   -- build your own private copy of it
>   -- check that it generates identical "configure"

Okay, but how do you run autoconf to regenerate gdb/configure?  I'm
used to have some Makefile rule to DTRT, but I cannot seem to find it
in the current CVS, or did I miss something?  (The reason I'm asking
something so stupid is because perhaps the errors I saw indicate that
I invoked autoconf incorrectly.)

> Do that before banging on configure.in

Sure.  For the moment, I've removed the change from configure.in, so
as not to break the CVS version.  This means that st_blocks in
remote-fileio.c is not the optimal value on _all_ platforms (since
HAVE_STRUCT_STAT_ST_BLOCKS is not defined anywhere), but at least GDB
will compile and run in a reasonable way.

> eli> Also, if it _is_ Autoconf 2.13, then it seems like it doesn't know
> eli> about AC_CHECK_MEMBER, so what should I put in configure.in for
> eli> testing the existence of st_blocks?
> 
> Maybe cut-and-paste from the l_addr check?

Thanks, I suspected that AC_TRY_COMPILE is the only way to go, but I
wasn't sure, as my autoconf experience is virtually non-existent.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]