Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Alexandre Oliva <aoliva@redhat.com>
To: Klee Dienes <klee@apple.com>
Cc: Andrew Cagney <ac131313@redhat.com>,
	binutils@sources.redhat.com, gdb-patches@sources.redhat.com,
	gcc@gcc.gnu.org, newlib@sources.redhat.com
Subject: Re: [RFC] Update to current automake/autoconf/libtool versions.
Date: Sun, 12 Jan 2003 13:22:00 -0000	[thread overview]
Message-ID: <orof6mwlkp.fsf@free.redhat.lsd.ic.unicamp.br> (raw)
In-Reply-To: <9A4230D6-1D26-11D7-BFCA-00039396EEB8@apple.com>

On Dec 31, 2002, Klee Dienes <klee@apple.com> wrote:

>>> * acinclude.m4: Remove include of libtool.m4.

>> Can't let you do that, Dave.  This causes us to use whatever
>> libtool.m4 happens to be in aclocal.m4's search path, which is very
>> likely not compatible with ltmain.sh from the top level.  That's why
>> we use libtool.m4 from the top level and keep all the libtool files in
>> sync.  I wouldn't mind updating to the libtool current CVS tree, which
>> would get us rid of a number of files in the top level, but this takes
>> a lot of testing on many different platforms.

> Given that in theory anyone running aclocal or autoconf should be
> running "official" and well-defined versions of those tools, they
> should also be getting correct values for the contents of libtool.m4.
> If their installed libtool.m4 is incompatible with the shipped
> ltmain.sh, who is to say that their installed acgeneral.m4 won't be
> incompatible with a shipped libtool.m4?  I'd argue that libtool.m4 is
> part of the autoconf environment, and that we should just require
> people running aclocal or autoconf to have the correct installations
> of the tools (as in theory we already do).

I disagree, and the libtool manual recommends this practice precisely
to make sure the libtool files remain in sync.  I see the revised
patch you just posted still has ChangeLog entries that say they're
removing the include statements.  I hope it was just a mistake.  If it
was not, please remove those changes and post a new patch, this time
copying gcc-patches@gcc.gnu.org instead of gcc@gcc.gnu.org.  Letting
random macros kick in from the user's installation of aclocal is a
mistake in general (or not kicking in at all, in case the
officially-recommended versions of automake and libtool were installed
in different prefixes), since there's no way to make sure they're
compatible with other files that may depend on it.  That's why there
is AC_PREREQ, but there's no such thing that affects aclocal's
behavior, so we're better off making sure we use the right version of
these files.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer


       reply	other threads:[~2003-01-12 13:22 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <9A4230D6-1D26-11D7-BFCA-00039396EEB8@apple.com>
2003-01-12 13:22 ` Alexandre Oliva [this message]
2002-12-06  5:28 Nathanael Nerode
  -- strict thread matches above, loose matches on Subject: below --
2002-12-05 14:42 Joern Rennecke
2002-12-05 14:40 Nathanael Nerode
2002-12-05 15:19 ` Zack Weinberg
2002-12-06 10:21   ` Tom Tromey
2002-12-07 13:06   ` Alexandre Oliva
2002-12-07 16:03     ` Zack Weinberg
2002-12-09 19:16       ` Alexandre Oliva
2002-12-09 21:52         ` Geoff Keating
2002-12-08 13:11     ` Tom Tromey
2002-12-05 11:08 Nathanael Nerode
2002-12-05 11:31 ` Andrew Cagney
2002-12-05 13:31 ` Zack Weinberg
2002-12-05 14:36   ` Alan Modra
2002-12-05 14:56     ` Ian Lance Taylor
2002-12-05 15:22       ` Alan Modra
2002-12-05 15:43         ` Ian Lance Taylor
2002-12-05 15:51           ` Andrew Cagney
2002-12-05 15:47         ` Mike Stump
2002-12-05 16:30           ` Alan Modra
2002-12-05 16:45             ` Zack Weinberg
2002-12-08  2:49         ` Klee Dienes
2002-12-05 14:29 ` Christopher Faylor
2002-12-06  6:45 ` Maciej W. Rozycki
2002-12-08 10:53 ` Klee Dienes
2002-12-05 10:15 Michael Elizabeth Chastain
2002-12-05 10:37 ` Klee Dienes
2002-11-13 10:32 [RFA/PATCH] Darwin fixes for ltconfig, ltcf-c.sh Klee Dienes
2002-12-04 22:04 ` [RFC] Update to current automake/autoconf/libtool versions Klee Dienes
2002-12-05  5:26   ` Hans-Peter Nilsson
2002-12-05 14:07     ` Alan Modra
2002-12-05  7:43   ` Andrew Cagney
2002-12-05  8:22     ` Klee Dienes
2002-12-05  9:01       ` Andrew Cagney
2002-12-05 12:55         ` Klee Dienes
2002-12-05 13:03           ` Daniel Jacobowitz
2002-12-05 13:13             ` Andrew Cagney
2002-12-05 13:16               ` Daniel Jacobowitz
2002-12-05 13:08           ` Andrew Cagney
2002-12-05 13:18             ` Klee Dienes
2002-12-05  8:28     ` DJ Delorie
2002-12-05  9:37       ` Klee Dienes
2002-12-05  9:42         ` DJ Delorie
2002-12-05 10:28           ` Klee Dienes
2002-12-05  9:31     ` H. J. Lu
2002-12-05  7:44   ` Maciej W. Rozycki
2002-12-05  9:01     ` Klee Dienes
2002-12-05  8:09   ` Daniel Jacobowitz
2002-12-05  8:29     ` DJ Delorie
2002-12-05  8:35       ` Daniel Jacobowitz
2002-12-05  8:37         ` DJ Delorie
2002-12-05  8:40         ` Maciej W. Rozycki
2002-12-05  8:44           ` Daniel Jacobowitz
2002-12-05  9:19             ` Elena Zannoni
2002-12-05  9:54             ` Klee Dienes
2002-12-05 10:10               ` Maciej W. Rozycki
2002-12-05 10:59               ` Andrew Cagney
2002-12-06  5:52                 ` Maciej W. Rozycki
2002-12-05 10:59               ` Doug Evans
2002-12-05 12:11                 ` Klee Dienes
2002-12-05 12:23                   ` Ian Lance Taylor
2002-12-05 14:29                     ` Klee Dienes
2002-12-06  5:34                 ` Maciej W. Rozycki
2002-12-06  7:25                   ` DJ Delorie
2002-12-06  8:06                     ` Maciej W. Rozycki
2002-12-06  8:47                       ` DJ Delorie
2002-12-05 13:59               ` Ben Elliston
2002-12-05 13:41                 ` Ben Elliston
2002-12-30 16:10   ` Alexandre Oliva

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=orof6mwlkp.fsf@free.redhat.lsd.ic.unicamp.br \
    --to=aoliva@redhat.com \
    --cc=ac131313@redhat.com \
    --cc=binutils@sources.redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=klee@apple.com \
    --cc=newlib@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