From: "Eli Zaretskii" <eliz@elta.co.il>
To: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] Fix compilation failure of remote-fileio.c
Date: Tue, 30 Dec 2003 09:12:00 -0000 [thread overview]
Message-ID: <2927-Tue30Dec2003111014+0200-eliz@elta.co.il> (raw)
In-Reply-To: <20031230082625.140414B35A@berman.michael-chastain.com> (mec.gnu@mindspring.com)
> 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.
next prev parent reply other threads:[~2003-12-30 9:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-30 8:26 Michael Elizabeth Chastain
2003-12-30 9:12 ` Eli Zaretskii [this message]
2003-12-30 10:34 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2003-12-30 19:20 Michael Elizabeth Chastain
2003-12-28 13:50 Eli Zaretskii
2003-12-28 23:38 ` Daniel Jacobowitz
2003-12-29 7:01 ` Eli Zaretskii
2003-12-29 16:01 ` Daniel Jacobowitz
2003-12-30 7:20 ` Eli Zaretskii
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=2927-Tue30Dec2003111014+0200-eliz@elta.co.il \
--to=eliz@elta.co.il \
--cc=gdb-patches@sources.redhat.com \
--cc=mec.gnu@mindspring.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