Re: [RFC] Update to current automake/autoconf/libtool versions.

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Nathanael Nerode]

Klee Dienes said:
>This patch is now broken as of the autoconfiscation of the top-level, 
>which unfortunately reverts to the previous behavior of passing 
>--build, --host, and --target down to the sub-configures at all times. I'm 
>working to make a patch for this, but am still caught up on updating the 
>GCC directories to work properly with automake-1.7.2, so it will 
>probably be another day or two.

Sadly, we need to 'reconstruct' the --build, --host, --target flags for
the build and target subdirs.

The 'correct' way to do this is probably:

* For the 'build' subdirs, pass --build only, and only if it was 
specified
* For the 'target' subdirs, pass --build iff it was specified, --host 
iff --target was specified, and never pass --target

Unfortunately this behavior *will not* work correctly until we update 
everything to autoconf 2.5x.  Hence my decision to pass down all three 
unconditionally.

Additionally, current versions of autoconf 2.5x are clever enough to 
realize that we're not cross-building if we specified --build and --host 
but they're the same, and we're not making a cross-compiler if we 
specified --host and --target but they're the same.  In other words, it 
behaves correctly even when we overspecify.

So I strongly suggest you get everything updated to autoconf 2.5x, and 
worry about what to pass down to subconfigures only after that is over.

--Nathanael

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Alexandre Oliva]

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

Re: [RFC] Update to current automake/autoconf/libtool versions

[Alexandre Oliva]

On Dec 12, 2002, Nathanael Nerode <neroden@twcny.rr.com> wrote:

> AC_PROG_CC and AC_PROG_CXX, at least in autoconf 2.13, simply didn't
> handle build!=host builds well.

?!?

> Furthermore, I needed an equivalent
> to find CC_FOR_TARGET and CXX_FOR_TARGET

We may need CC_FOR_BUILD too.  At least gcc and sim need it.

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

Re: [RFC] Update to current automake/autoconf/libtool versions

[Nathanael Nerode]

Zack Weinberg wrote:
> Nathanael Nerode <neroden@twcny.rr.com> writes:
> 
> 
>>*twisted half-grin*
>>
>>For the top level, I'd been unable to avoid writing 
>>complete replacements for AC_PROG_CC and AC_PROG_CXX, and it
>>was really nasty.
>>
>>So this is actually better than I'd hoped.
> 
> 
> Can you explain a bit about why this is necessary?  It's not at all
> obvious to me.

AC_PROG_CC and AC_PROG_CXX, at least in autoconf 2.13, simply didn't 
handle build!=host builds well.  Furthermore, I needed an equivalent to 
find CC_FOR_TARGET and CXX_FOR_TARGET, and there's no such thing, which 
left me making a replacement.  Not a very different replacement, mind you.

--Nathanael

--Nathanael

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Henry Nelson]

> I don't get it.  Why does being able to link have anything to do with
> being native?  Being able to *run* tests has to do with being native,
> but that's not the point, and autoconf already avoids running tests
> when cross-building.  But being able to link has to do with whether

While I don't understand it, this kind of discussion seems to come the
closest in relevance to problems (inability to link, or executables built
that can't find the necessary runtime libraries) I have experienced on
Solaris2.6 after updating to: autoconf-2.56, gcc3.2.1/binutils2.13.1
(ld version 2.13.1).  Details on gcc:
    Configured with: ../gcc-3.2.1/configure --prefix=/opt/gnu
    --disable-nls --enable-languages=c,c++ --enable-static
    --enable-shared --enable-version-specific-runtime-libs --with-gnu-as
    --with-as=/opt/gnu/bin/as --with-gnu-ld --with-ld=/opt/gnu /bin/ld
    --infodir=/usr/local/info --mandir=/usr/local/man --with-libiconv-prefix
    =/usr/local     Thread model: posix

I'm hoping that someone more knowledgeable will be able to write a bug
report and submit it to the developers of the relevant program.  Unless
something is corrected, gcc in its present state is of little use to people
on Solaris2.x as a native compiler.  Personally, I've gone back to 2.7.2.3
until the 3.2 branch is truly ported to Solaris2.x as a native compiler.

As I've already mentioned in previous posts ("how do you get gcc with gnu
ld to work on solaris2.x?", http://gcc.gnu.org/ml/gcc/2002-12/msg00252.html),
too much manual doctoring of variables like LDFLAGS and LIBS has to be done.

For example, in order to compile libiconv (also libtool), the following
environment variables have to be set before running the configure script:
     setenv LDFLAGS "-L/opt/gnu/lib -lgcc_s -R/opt/gnu/lib"
     setenv LIBS "/opt/gnu/lib/libgcc_s.so.1 -Wl,-rpath -Wl,/opt/gnu/lib"
If gcc/ld doesn't have enough sense to do this on its own, then it has no
business using shared objects at all, IMNSHO.

By far the worst experience I've had is with the mail client mutt.  Even
now I have found no solution after weeks of struggling and asking around:
    With configure options "--with-libiconv-prefix=/usr/local
    --with-slang=/usr/local":
       checking whether this iconv is good enough... no
       configure: error: Try using libiconv instead
    So I try to tell the configure script that I do have libiconv
    by adding environment variables 'LDFLAGS "-L/usr/local/lib -liconv
    -R/usr/local/lib" LIBS "/usr/local/lib/libiconv.so -Wl,-rpath
    -Wl,/usr/local/lib"':
       checking whether byte ordering is bigendian... configure: error:
       can not run test program while cross compiling
    Then unsetenv the above, and try a hint I got off of the Internet
    "LD_PRELOAD /usr/local/lib/libiconv_plug.so":
       ld.so.1: sed: fatal: relocation error: file
       /usr/local/lib/libiconv_plug.so: symbol main: referenced symbol
       not found configure: error: can not find sources in  or ..

I can only keep my fingers crossed so long before I just have to move on.

henry nelson

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Geoff Keating]

Alexandre Oliva <aoliva@redhat.com> writes:

> I don't get it.  Why does being able to link have anything to do with
> being native?  Being able to *run* tests has to do with being native,
> but that's not the point, and autoconf already avoids running tests
> when cross-building.  But being able to link has to do with whether
> the libraries that the compiler links in by default are present or
> not.  That's the purpose of AC_NO_EXECUTABLES: to disable link tests
> while building a library that the compiler driver would attempt to link
> in by default, such as newlib, libstdc++ or libgcj.

Aah, I see.  No, that's not the purpose of AC_NO_EXECUTABLES, or at
least it's not what GCC wants out of it.  Some platforms can't link
anything at all without special care.  For instance, you might need to
know what board you plan to run the executable on and pass an
appropriate flag (or supply an appropriate crt0 by hand).  For another
example, vxworks can't and doesn't link anything, the final link takes
place at runtime on the board, "executables" are created using 'ld
-r', and you can refer to any symbols you like in the hope that
they'll be available later.

It's assumed that in a native case, this sort of thing won't happen,
thus the existing behaviour.  Maybe instead you could perform a
configure-time test to see if the platform can link anything at all
(and will fail to link with an obviously bogus symbol), and then base
the decision of whether to run link tests on that, instead of the
current approximation, but there'll still be some cases when linking
is not possible, and other cases (the majority) in which link tests
are possible and desirable.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Alexandre Oliva]

On Dec  7, 2002, Zack Weinberg <zack@codesourcery.com> wrote:

> Alexandre Oliva <aoliva@redhat.com> writes:
>> On Dec  5, 2002, Zack Weinberg <zack@codesourcery.com> wrote:
>> 
>>> AC_NO_EXECUTABLES has two effects: (1) it disables the equivalent of
>>> AC_PROG_CC_WORKS, which is what we need.  But, (2) it causes autoconf
>>> to barf if an AC_TRY_LINK test appears anywhere in the script being
>>> generated.
>> 
>> Please tell me why (2) doesn't make sense.
>> 
>> If AC_PROG_CC_WORKS can't even link a do-nothing program, how would
>> you expect to get any useful results from AC_TRY_LINK?

> Because libstdc++'s AC_TRY_LINK tests are only executed in a situation
> where AC_PROG_CC_WORKS would have succeeded (i.e. a native compilation).

I don't get it.  Why does being able to link have anything to do with
being native?  Being able to *run* tests has to do with being native,
but that's not the point, and autoconf already avoids running tests
when cross-building.  But being able to link has to do with whether
the libraries that the compiler links in by default are present or
not.  That's the purpose of AC_NO_EXECUTABLES: to disable link tests
while building a library that the compiler driver would attempt to link
in by default, such as newlib, libstdc++ or libgcj.

That said, I'm not sure it should be used for libstdc++, since there's
no reason to use g++: we should use gcc instead, even if we perform
C++ link tests.  Ditto for libjava, I suppose, but I realize it would
be far trickier to get libjava to link C programs :-)

Still, I think AC_NO_EXECUTABLES may affect all linking whatsoever,
not only that of the language in effect at the point it appears, which
does indeed make it useless for anything other that newlib.  But, for
newlib, preventing link tests *is* the right thing to do, and I
contend that it's the right thing to do for any language affected by
the AC_NO_EXECUTABLES declaration.

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

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Tom Tromey]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

>> But, (2) it causes autoconf to barf if an AC_TRY_LINK test appears
>> anywhere in the script being generated.

Alexandre> Please tell me why (2) doesn't make sense.

Alexandre> If AC_PROG_CC_WORKS can't even link a do-nothing program,
Alexandre> how would you expect to get any useful results from
Alexandre> AC_TRY_LINK?

The autoconf code in question completely disables AC_LINK_IFELSE.
However, we know we can successfully do link tests when building
natively.  And, at least in libgcj's case, this knowledge is important
because we use it to make libgcj more functional when built native.

FYI I sent a patch to the autoconf list.

Tom

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Klee Dienes]

[-- Attachment #1: Type: text/plain, Size: 1807 bytes --]

On Thursday, December 5, 2002, at 02:07 PM, Nathanael Nerode wrote:
>
> Unfortunately I think some other aspects of the configure scripts
> require --target to be passed down unconditionally. :-/  Otherwise I'd
> just change it.

There's a useful thread on the host/target/build business in 
http://sources.redhat.com/ml/autoconf/2002-02/msg00059.html (which I 
imagine you're already familiar with, but it makes a nice reference).

I did some preliminary experiments with modifying what the top-level 
configure passes down, and at least from the binutils/gdb side of 
things, it looked promising.  I ended up changing the top-level 
configure semantics to match that of autoconf:

	configure --build=BUILD --host=HOST --target=TARGET UNDEFS

	1. You aren't allowed to specify --host, --build, --target, and undefs 
at the same time.
	2. Build defaults to undefs.
	3. If undefs is not specified, then build defaults to the current 
host, as determined by config.guess.
	4. Host defaults to undefs.
	5. If undefs is not specified, then host defaults to build.
	6. Target defaults to undefs.
	7. If undefs is not specified, then target defaults to host.

	passing --host means you cross compile (whatever the relationship 
between host and build)
	passing --target means you build a cross-tool (whatever the 
relationship between host and target).

	--host and --target are only passed to sub-configures if they were 
explicitly passed to the top-level configure on the command-line.

This fixed the problem with things installing in the wrong places; the 
only fallout was that the emulation-selection code in binutils/ needed 
to be changed to refer to $target instead of $target_alias.  A basic 
gcc build appeared to work, but I didn't try anything more complicated 
than a stadard cross-compile setup.


[-- Attachment #2: ChangeLog --]
[-- Type: application/octet-stream, Size: 3396 bytes --]

.
2002-12-04  Klee Dienes  <kdienes@apple.com>

	* .cvsignore: Add autom4te.cache.

	* configure: Change the rules for build/host/target processing to
	the following:
	
	The inputs are:
	  configure --build=BUILD --host=HOST --target=TARGET UNDEFS
	
	The rules are:
	  1. You aren't allowed to specify --host, --build, --target, and
	     undefs at the same time.
	  2. Build defaults to undefs.
	  3. If undefs is not specified, then build defaults to the current
	     host, as determined by config.guess.
	  4. Host defaults to undefs.
	  5. If undefs is not specified, then host defaults to build.
	  6. Target defaults to undefs.
	  7. If undefs is not specified, then target defaults to host.
	
	Only pass --host= and --target= to sub-configures when they are
	passed by the top-level configure.  Treat the build as a
	cross-compilation whenever --target is specified, even if it
	matches the value of --build and --host.
	
bfd
2002-12-04  Klee Dienes  <kdienes@apple.com>

	* acinclude.m4: Remove include of libtool.m4.
	* configure.in: Use AC_DISABLE_SHARED and AC_PROG_LIBTOOL
	instead of the AM_ versions.

binutils
2002-12-04  Klee Dienes  <kdienes@apple.com>

	* Makefile.am (YLWRAP): Refer to the top-level ylwrap.
	* acinclude.m4: Remove include of libtool.m4.
	* configure.in: Use AC_PROG_LEX instead of AM_PROG_LEX.
        (EMULATION): Use $target, not $target_alias.
		
gas
2002-12-04  Klee Dienes  <kdienes@apple.com>

	* acinclude.m4: Remove include of libtool.m4.
	* configure.in: Pass explicit value to AC_CONFIG_FILES, not
	${GDBINIT}.  Use AC_CONFIG_FILES, AC_CONFIG_COMMANDS, and
	AC_OUTPUT, not the multi-argument AC_OUTPUT.

gdb
2002-12-04  Klee Dienes  <kdienes@apple.com>

	* Makefile.in: Update to new ylwrap calling conventions.
	* configure.in: Pass description string to AC_DEFINE.

gdb/testsuite
2002-12-04  Klee Dienes  <kdienes@apple.com>

	* gdb.hp/gdb.objdbg/configure.in: Remove objdbg0* from
	AC_CONFIG_SUBDIRS.

gprof
2002-12-04  Klee Dienes  <kdienes@apple.com>

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

ld
2002-12-04  Klee Dienes  <kdienes@apple.com>

	* Makefile.am (YLWRAP): Refer to the top-level ylwrap.
	* acinclude.m4: Remove include of libtool.m4.

libiberty
2002-12-04  Klee Dienes  <kdienes@apple.com>

	* aclocal.m4: Use AC_LIBOBJ instead of setting LIBOBJS directly.
	Use _AC_LANG_COMPILER_GNU and $ac_compiler_gnu instead of
	AC_PROG_CC_GNU and $ac_cv_prog_gcc.  Call _AC_COMPILER_OBJEXT to
	get the object file extension.  Use AC_PROG_CC_G instead of
	_AC_PROG_CC_G.
	* configure.in: Use AC_LIBOBJ instead of setting LIBOBJS directly.

opcodes
2002-12-04  Klee Dienes  <kdienes@apple.com>

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

rda
2002-12-04  Klee Dienes  <kdienes@apple.com>

	* configure.in: Use AC_PROG_LIBTOOL instead of AM_PROG_LIBTOOL.


rda/lib
2002-12-04  Klee Dienes  <kdienes@apple.com>

	* lib/Makefile.am: Remove noinst_LIBRARIES and librda_a_SOURCES
	(it's not possible to specify both a libtool version and a
	non-libtool version using the same object files).

rda/unix
2002-12-04  Klee Dienes  <kdienes@apple.com>

	* unix/configure.in: Pass description strings to AC_DEFINE.

rda/win32
2002-12-04  Klee Dienes  <kdienes@apple.com>

	* win32/configure.in: Pass description strings to AC_DEFINE.

sim/common
2002-12-04  Klee Dienes  <kdienes@apple.com>
	
	* aclocal.m4: Pass description strings to AC_DEFINE.

[-- Attachment #3: files.sh --]
[-- Type: application/octet-stream, Size: 1177 bytes --]

echo "Versions:"

dir=`echo $0 | sed -e 's/\/[^\/]*$//'`
echo $dir

libtool --version | grep \. | grep '(' | grep -v Copy 2>&1
autoconf --version | grep \. | grep '(' | grep -v Copy 2>&1
automake --version | grep \. | grep '(' | grep -v Copy 2>&1
gettext --version | grep \. | grep '(' | grep -v Copy 2>&1

# update=`grep '+++' $dir/bfd.txt | sed -e 's/+++ //' -e 's/[ 	].*//'`
# echo; echo Resetting:
# echo Removing $update
# rm -f $update
# cvs -z9 -q update $update

find . -name autom4te.cache | xargs rm -rf

echo; echo "Patching:"

patch -p0 < $dir/bfd.txt

cp -p /usr/share/automake-1.7/depcomp .
cp -p /usr/share/automake-1.7/missing .
cp -p /usr/share/automake-1.7/mkinstalldirs .
cp -p /usr/share/automake-1.7/ylwrap .

cp -p /usr/share/libtool/ltmain.sh .

rm -f ltcf-c.sh
rm -f ltcf-cxx.sh
rm -f ltcf-gcj.sh
rm -f ltconfig
rm -f libtool.m4

echo; echo "Configuring:"

dirs="bfd binutils gas gdb gprof ld libiberty mmalloc opcodes rda sim utils"
for i in $dirs; do
    dirs=`find $i -type d`
    dirs=`for j in $dirs; do if [ -f $j/configure.in ]; then echo $j; fi; done`
    for j in $dirs; do
        echo "Configuring $j"
	autoreconf -f -I`pwd` $j
    done
done

[-- Attachment #4: bfd.txt --]
[-- Type: text/plain, Size: 40089 bytes --]

--- .cvsignore	2002-12-04 12:16:15.000000000 -0500
+++ .cvsignore	2002-12-04 23:18:08.000000000 -0500
@@ -6,6 +6,7 @@
 *-src
 *-stamp-*
 *-tagged
+autom4te.cache
 blockit
 cfg-paper.info
 config.status
--- configure	Sat Nov 30 23:42:45 2002
+++ configure	Sun Dec  8 01:08:59 2002
@@ -47,7 +47,7 @@
 Makefile=Makefile
 Makefile_in=Makefile.in
 arguments=
-build_alias=
+build_alias=NOBUILD
 cache_file=config.cache
 cache_file_option=
 configdirs=
@@ -400,71 +400,99 @@
 	esac
 done
 
-# process host and target
+# process build, host, and target
 
 # Do some error checking and defaulting for the host and target type.
 # The inputs are:
-#    configure --host=HOST --target=TARGET UNDEFS
+#    configure --build=BUILD --host=HOST --target=TARGET UNDEFS
 #
 # The rules are:
-# 1. You aren't allowed to specify --host, --target, and undefs at the
-#    same time.
-# 2. Host defaults to undefs.
-# 3. If undefs is not specified, then host defaults to the current host,
+# 1. You aren't allowed to specify --host, --build, --target, and undefs
+#    at the same time.
+# 2. Build defaults to undefs.
+# 3. If undefs is not specified, then build defaults to the current host,
 #    as determined by config.guess.
-# 4. Target defaults to undefs.
-# 5. If undefs is not specified, then target defaults to host.
+# 4. Host defaults to undefs.
+# 5. If undefs is not specified, then host defaults to build.
+# 6. Target defaults to undefs.
+# 7. If undefs is not specified, then target defaults to host.
 
 case "${fatal}" in
 "")
 	# Make sure that host, target & undefs aren't all specified at the
 	# same time.
-	case $host_alias---$target_alias---$undefs in
-	NOHOST---*---* | *---NOTARGET---* | *---*---NOUNDEFS)
+	case $build_alias---$host_alias---$target_alias---$undefs in
+	NOBUILD---*---*---* | *---NOHOST---*---* | *---*---NOTARGET---* | *---*---*---NOUNDEFS)
 		;;
-	*) echo '***' Can only configure for one host and one target at a time.  1>&2
+	*) echo '***' Can only configure for one build, host and target at a time.  1>&2
 	   fatal=yes
 	   break 2
 		;;
 	esac
 
-	# Now, do defaulting for host.
-	case $host_alias in
-	NOHOST)
+	# Do defaulting for build.
+	case $build_alias in
+	NOBUILD)
 		case $undefs in
 		NOUNDEFS)
-			# Neither --host option nor undefs were present.
+			# Neither --build option nor undefs were present.
 			# Call config.guess.
 			guesssys=`echo ${progname} | sed 's/configure$/config.guess/'`
-			if host_alias=`${config_shell} ${guesssys}`
+			if build_alias=`${config_shell} ${guesssys}`
 			then
 				# If the string we are going to use for
 				# the target is a prefix of the string
-				# we just guessed for the host, then
+				# we just guessed for the build, then
 				# assume we are running native, and force
-				# the same string for both target and host.
+				# the same string for both target and build.
 				case $target_alias in
 				NOTARGET) ;;
 				*)
-					if expr $host_alias : $target_alias >/dev/null
+					if expr $build_alias : $target_alias >/dev/null
 					then
-						host_alias=$target_alias
+					    	echo "The target type ($target_alias) is a prefix of the build type ($build_alias)."
+						echo "Using $target_alias as the new build type."
+						build_alias=$target_alias
 					fi
 					;;
 				esac
-				echo "Configuring for a ${host_alias} host."
-				arguments="--host=$host_alias $arguments"
+				buildopt="--build=${build_alias}"
+				arguments="$buildopt $arguments"
 			else
-				echo 'Config.guess failed to determine the host type.  You need to specify one.' 1>&2
+				echo 'Config.guess failed to determine the build type.  You need to specify one.' 1>&2
 				fatal=yes
 			fi
 			;;
 		*)
+			build_alias=$undefs
+			buildopt="--build=${build_alias}"
+			arguments="$buildopt $arguments"
+			;;
+		esac
+		;;
+	*)
+		buildopt="--build=${build_alias}"
+		;;
+	esac
+
+	# Do defaulting for host.  If --host option isn't present, default
+	# to undefs.  If undefs isn't present, default to host.
+	case $host_alias in
+	NOHOST)
+		case $undefs in
+		NOUNDEFS)
+			host_alias="$build_alias"
+			;;
+		*)
 			host_alias=$undefs
-			arguments="--host=$host_alias $arguments"
-			undefs=NOUNDEFS
+			hostopt="--host=${host_alias}"
+			arguments="$hostopt $arguments"
 			;;
 		esac
+		;;
+	*)
+		hostopt="--host=${host_alias}"
+		;;
 	esac
 
 	# Do defaulting for target.  If --target option isn't present, default
@@ -473,13 +501,18 @@
 	NOTARGET)
 		case $undefs in
 		NOUNDEFS)
-			target_alias=$host_alias
+			target_alias="$host_alias"
 			;;
 		*)
 			target_alias=$undefs
-			arguments="--target=$target_alias $arguments"
+			targetopt="--target=${target_alias}"
+			arguments="$targetopt $arguments"
 			;;
 		esac
+		;;
+	*)
+		targetopt="--target=${target_alias}"
+		;;
 	esac
 	;;
 *) ;;
@@ -622,12 +655,8 @@
 	    *)  cache_file_option="--cache-file=${cache_file}" ;;
 	    esac
 	    srcdiroption="--srcdir=${srcdir}"
-	    case "${build_alias}" in
-	    "") buildopt= ;;
-	    *)  buildopt="--build=${build_alias}" ;;
-	    esac
 	    eval exec ${config_shell} ${srcdir}/configure ${verbose} \
-		${buildopt} --host=${host_alias} --target=${target_alias} \
+		${buildopt} ${hostopt} ${targetopt} \
 		${prefixoption} ${tmpdiroption} ${exec_prefixoption} \
 		${srcdiroption} ${diroptions} \
 		${program_prefixoption} ${program_suffixoption} \
@@ -709,29 +738,16 @@
 *) ;;
 esac
 
-case "${build_alias}" in
-"")
-	if result=`${config_shell} ${configsub} ${host_alias}` ; then
-	    build_cpu=`echo $result | sed 's/^\([^-]*\)-\([^-]*\)-\(.*\)$/\1/'`
-	    build_vendor=`echo $result | sed 's/^\([^-]*\)-\([^-]*\)-\(.*\)$/\2/'`
-	    build_os=`echo $result | sed 's/^\([^-]*\)-\([^-]*\)-\(.*\)$/\3/'`
-	    build=${build_cpu}-${build_vendor}-${build_os}
-	    build_alias=${host_alias}
-	fi
-	;;
-*)
-	if result=`${config_shell} ${configsub} ${build_alias}` ; then
-	    buildopt="--build=${build_alias}"
-	    build_cpu=`echo $result | sed 's/^\([^-]*\)-\([^-]*\)-\(.*\)$/\1/'`
-	    build_vendor=`echo $result | sed 's/^\([^-]*\)-\([^-]*\)-\(.*\)$/\2/'`
-	    build_os=`echo $result | sed 's/^\([^-]*\)-\([^-]*\)-\(.*\)$/\3/'`
-	    build=${build_cpu}-${build_vendor}-${build_os}
-	else
-	    echo "Unrecognized build system name ${build_alias}." 1>&2
-	    exit 1
-	fi
-	;;
-esac
+if result=`${config_shell} ${configsub} ${build_alias}` ; then
+    true
+else
+    echo "Unrecognized build system name ${build_alias}." 1>&2
+    exit 1
+fi
+build_cpu=`echo $result | sed 's/^\([^-]*\)-\([^-]*\)-\(.*\)$/\1/'`
+build_vendor=`echo $result | sed 's/^\([^-]*\)-\([^-]*\)-\(.*\)$/\2/'`
+build_os=`echo $result | sed 's/^\([^-]*\)-\([^-]*\)-\(.*\)$/\3/'`
+build=${build_cpu}-${build_vendor}-${build_os}
 
 if result=`${config_shell} ${configsub} ${host_alias}` ; then
     true
@@ -759,6 +775,24 @@
 
 . ${tmpfile}.tgt
 
+if [ "$build_alias" != "$build" ]; then
+    echo "Configuring for a ${build_alias} (${build}) build."
+else
+    echo "Configuring for a ${build_alias} build."
+fi
+
+if [ "$host_alias" != "$host" ]; then
+    echo "Configuring for a ${host_alias} (${host}) host."
+else
+    echo "Configuring for a ${host_alias} host."
+fi
+
+if [ "$target_alias" != "$target" ]; then
+    echo "Configuring for a ${target_alias} (${target}) target."
+else
+    echo "Configuring for a ${target_alias} target."
+fi
+
 # Find the source files, if location was not specified.
 case "${srcdir}" in
 "")
@@ -785,7 +819,7 @@
 # using) don't handle "\$" correctly, so don't use it here.
 tooldir='$(exec_prefix)'/${target_alias}
 
-if [ "${host_alias}" != "${target_alias}" ] ; then
+if [ -n "${target_alias}" ] ; then
     if [ "${program_prefixoption}" = "" ] ; then
         if [ "${program_suffixoption}" = "" ] ; then 
             if [ "${program_transform_nameoption}" = "" ] ; then
@@ -1520,7 +1554,7 @@
 
 ### The recursion line is here.
 			if [ ! -z "${recprog}" ] ; then
-	                        if eval ${config_shell} ${recprog} ${verbose} ${buildopt} --host=${host_alias} --target=${tgt_alias} \
+	                        if eval ${config_shell} ${recprog} ${verbose} ${buildopt} ${hostopt} ${targetopt} \
         	                        ${prefixoption} ${tmpdiroption} ${exec_prefixoption} \
                 	                ${srcdiroption} ${diroptions} ${program_prefixoption} ${program_suffixoption} ${program_transform_nameoption} ${site_option} ${withoptions} ${withoutoptions} ${enableoptions} ${disableoptions} ${floating_pointoption} ${cache_file_option} ${other_options} ${redirect} ; then
 	                                true
--- bfd/acinclude.m4	2002-12-04 12:16:19.000000000 -0500
+++ bfd/acinclude.m4	2002-12-04 23:18:08.000000000 -0500
@@ -108,16 +108,6 @@
  AC_MSG_RESULT($bfd_cv_have_sys_procfs_type_member_$1_$2)
 ])
 
-sinclude(../libtool.m4)
-dnl The lines below arrange for aclocal not to bring libtool.m4
-dnl AM_PROG_LIBTOOL into aclocal.m4, while still arranging for automake
-dnl to add a definition of LIBTOOL to Makefile.in.
-ifelse(yes,no,[
-AC_DEFUN([AM_PROG_LIBTOOL],)
-AC_DEFUN([AM_DISABLE_SHARED],)
-AC_SUBST(LIBTOOL)
-])
-
 sinclude(../gettext.m4)
 ifelse(yes,no,[
 AC_DEFUN([CY_WITH_NLS],)
--- bfd/configure.in	2002-12-04 12:16:20.000000000 -0500
+++ bfd/configure.in	2002-12-04 23:18:08.000000000 -0500
@@ -23,16 +23,16 @@
 AC_SUBST(bfd_version)
 AC_SUBST(bfd_version_string)
 
-dnl These must be called before AM_PROG_LIBTOOL, because it may want
+dnl These must be called before AC_PROG_LIBTOOL, because it may want
 dnl to call AC_CHECK_PROG.
 AC_CHECK_TOOL(AR, ar)
 AC_CHECK_TOOL(RANLIB, ranlib, :)
 
 dnl Default to a non shared library.  This may be overridden by the
 dnl configure option --enable-shared.
-AM_DISABLE_SHARED
+AC_DISABLE_SHARED
 
-AM_PROG_LIBTOOL
+AC_PROG_LIBTOOL
 
 AC_ARG_ENABLE(64-bit-bfd,
 [  --enable-64-bit-bfd     64-bit support (on hosts with narrower word sizes)],
--- binutils/Makefile.am	2002-12-04 12:16:22.000000000 -0500
+++ binutils/Makefile.am	2002-12-04 23:18:08.000000000 -0500
@@ -15,6 +15,8 @@
 CC_FOR_BUILD = @CC_FOR_BUILD@
 EXEEXT_FOR_BUILD = @EXEEXT_FOR_BUILD@
 
+YLWRAP = $(srcdir)/../ylwrap
+
 YACC = `if [ -f ../bison/bison ]; then echo ../bison/bison -y -L$(srcdir)/../bison/; else echo @YACC@; fi`
 YFLAGS = -d
 LEX = `if [ -f ../flex/flex ]; then echo ../flex/flex; else echo @LEX@; fi`
--- binutils/acinclude.m4	2002-12-04 12:16:23.000000000 -0500
+++ binutils/acinclude.m4	2002-12-04 23:18:08.000000000 -0500
@@ -1,14 +1,5 @@
 sinclude(../bfd/acinclude.m4)
 
-dnl sinclude(../libtool.m4) already included in bfd/acinclude.m4
-dnl The lines below arrange for aclocal not to bring libtool.m4
-dnl AM_PROG_LIBTOOL into aclocal.m4, while still arranging for automake
-dnl to add a definition of LIBTOOL to Makefile.in.
-ifelse(yes,no,[
-AC_DEFUN([AM_PROG_LIBTOOL],)
-AC_SUBST(LIBTOOL)
-])
-
 dnl sinclude(../gettext.m4) already included in bfd/acinclude.m4
 ifelse(yes,no,[
 AC_DEFUN([CY_WITH_NLS],)
--- binutils/configure.in	2002-12-04 12:16:23.000000000 -0500
+++ binutils/configure.in	2002-12-04 23:18:08.000000000 -0500
@@ -62,7 +62,7 @@
 AC_PROG_CC
 
 AC_PROG_YACC
-AM_PROG_LEX
+AC_PROG_LEX
 
 ALL_LINGUAS="fr tr ja es sv da"
 CY_GNU_GETTEXT
@@ -320,7 +320,7 @@
  [Define to 1 if user symbol names have a leading underscore, 0 if not.])
 
 # Emulation 
-for targ_alias in `echo $target_alias $enable_targets | sed 's/,/ /g'`
+for targ_alias in `echo $target $enable_targets | sed 's/,/ /g'`
 do
   # Canonicalize the secondary target names.
  result=`$ac_config_sub $targ_alias 2>/dev/null`
--- gas/acinclude.m4	2002-12-04 12:16:34.000000000 -0500
+++ gas/acinclude.m4	2002-12-04 23:18:08.000000000 -0500
@@ -55,16 +55,6 @@
 $1=[$]_gas_uniq_newlist
 ])dnl
 
-sinclude(../libtool.m4)
-dnl The lines below arrange for aclocal not to bring libtool.m4
-dnl AM_PROG_LIBTOOL into aclocal.m4, while still arranging for automake
-dnl to add a definition of LIBTOOL to Makefile.in.
-ifelse(yes,no,[
-AC_DEFUN([AM_PROG_LIBTOOL],)
-AC_DEFUN([AC_CHECK_LIBM],)
-AC_SUBST(LIBTOOL)
-])
-
 sinclude(../gettext.m4)
 ifelse(yes,no,[
 AC_DEFUN([CY_WITH_NLS],)
--- gas/configure.in	2002-12-04 12:16:35.000000000 -0500
+++ gas/configure.in	2002-12-04 23:18:08.000000000 -0500
@@ -70,10 +70,14 @@
 
 # If we are on a DOS filesystem, we must use gdb.ini rather than
 # .gdbinit.
-GDBINIT=".gdbinit"
 case "${host}" in
   *-*-msdos* | *-*-go32* | *-*-mingw32* | *-*-windows*)
     GDBINIT="gdb.ini"
+    AC_CONFIG_FILES(gdb.ini:gdbinit.in)
+    ;;
+  *)
+    GDBINIT=".gdbinit"
+    AC_CONFIG_FILES(.gdbinit:gdbinit.in)
     ;;
 esac
 AC_SUBST(GDBINIT)
@@ -993,7 +997,9 @@
 dnl the old symlinks don't exist, so that a reconfigure in an existing
 dnl directory behaves reasonably.
 
-AC_OUTPUT(Makefile doc/Makefile ${GDBINIT}:gdbinit.in po/Makefile.in:po/Make-in,
+AC_CONFIG_FILES(Makefile doc/Makefile po/Makefile.in:po/Make-in)
+
+AC_CONFIG_COMMANDS([default],
 [rm -f targ-cpu.c targ-cpu.h obj-format.h obj-format.c targ-env.h atof-targ.c itbl-cpu.h
  echo '#include "tc-'"${target_cpu_type}"'.h"' > targ-cpu.h
  echo '#include "obj-'"${obj_format}"'.h"' > obj-format.h
@@ -1008,3 +1014,5 @@
  cgen_cpu_prefix=${cgen_cpu_prefix}
  obj_format=${obj_format}
  te_file=${te_file}])
+
+AC_OUTPUT
\ No newline at end of file
--- gdb/Makefile.in	2002-12-04 23:11:12.000000000 -0500
+++ gdb/Makefile.in	2002-12-04 23:18:08.000000000 -0500
@@ -1218,7 +1218,7 @@
 .PRECIOUS: c-exp.tab.c
 c-exp.tab.o: c-exp.tab.c
 c-exp.tab.c: c-exp.y
-	$(SHELL) $(YLWRAP) "$(YACC)" $(srcdir)/c-exp.y  y.tab.c c-exp.tmp -- $(YFLAGS) 
+	$(SHELL) $(YLWRAP) $(srcdir)/c-exp.y  y.tab.c c-exp.tmp -- "$(YACC)" $(YFLAGS) 
 	-sed -e '/extern.*malloc/d' \
 	     -e '/extern.*realloc/d' \
 	     -e '/extern.*free/d' \
@@ -1234,7 +1234,7 @@
 .PRECIOUS: objc-exp.tab.c
 objc-exp.tab.o: objc-exp.tab.c
 objc-exp.tab.c: objc-exp.y
-	$(SHELL) $(YLWRAP) "$(YACC)" $(srcdir)/objc-exp.y y.tab.c objc-exp.tmp -- $(YFLAGS) 
+	$(SHELL) $(YLWRAP) $(srcdir)/objc-exp.y y.tab.c objc-exp.tmp -- "$(YACC)" $(YFLAGS) 
 	-sed -e '/extern.*malloc/d' \
 	     -e '/extern.*realloc/d' \
 	     -e '/extern.*free/d' \
@@ -1250,7 +1250,7 @@
 .PRECIOUS: jv-exp.tab.c
 jv-exp.tab.o: jv-exp.tab.c
 jv-exp.tab.c: jv-exp.y
-	$(SHELL) $(YLWRAP) "$(YACC)" $(srcdir)/jv-exp.y  y.tab.c jv-exp.tmp -- $(YFLAGS) 
+	$(SHELL) $(YLWRAP) $(srcdir)/jv-exp.y  y.tab.c jv-exp.tmp -- "$(YACC)" $(YFLAGS) 
 	-sed -e '/extern.*malloc/d' \
 	     -e '/extern.*realloc/d' \
 	     -e '/extern.*free/d' \
@@ -1266,7 +1266,7 @@
 .PRECIOUS: f-exp.tab.c
 f-exp.tab.o: f-exp.tab.c
 f-exp.tab.c: f-exp.y
-	$(SHELL) $(YLWRAP) "$(YACC)" $(srcdir)/f-exp.y  y.tab.c f-exp.tmp -- $(YFLAGS) 
+	$(SHELL) $(YLWRAP) $(srcdir)/f-exp.y  y.tab.c f-exp.tmp -- "$(YACC)" $(YFLAGS) 
 	-sed -e '/extern.*malloc/d' \
 	     -e '/extern.*realloc/d' \
 	     -e '/extern.*free/d' \
@@ -1282,7 +1282,7 @@
 .PRECIOUS: m2-exp.tab.c
 m2-exp.tab.o: m2-exp.tab.c
 m2-exp.tab.c: m2-exp.y
-	$(SHELL) $(YLWRAP) "$(YACC)" $(srcdir)/m2-exp.y  y.tab.c m2-exp.tmp -- $(YFLAGS) 
+	$(SHELL) $(YLWRAP) $(srcdir)/m2-exp.y  y.tab.c m2-exp.tmp -- "$(YACC)" $(YFLAGS) 
 	-sed -e '/extern.*malloc/d' \
 	     -e '/extern.*realloc/d' \
 	     -e '/extern.*free/d' \
@@ -1298,7 +1298,7 @@
 .PRECIOUS: ada-exp.tab.c
 ada-exp.tab.o: ada-exp.tab.c
 ada-exp.tab.c: ada-exp.y 
-	$(YACC) $(YFLAGS) $(srcdir)/ada-exp.y
+	$(SHELL) $(YLWRAP) $(srcdir)/ada-exp.y  y.tab.c ada-exp.tmp -- "$(YACC)" $(YFLAGS) 
 	-sed -e '/extern.*malloc/d' \
 	-e '/extern.*realloc/d' \
 	-e '/extern.*free/d' \
@@ -1327,7 +1327,7 @@
 .PRECIOUS: p-exp.tab.c
 p-exp.tab.o: p-exp.tab.c
 p-exp.tab.c: p-exp.y
-	$(SHELL) $(YLWRAP) "$(YACC)" $(srcdir)/p-exp.y  y.tab.c p-exp.tmp -- $(YFLAGS)
+	$(SHELL) $(YLWRAP) $(srcdir)/p-exp.y  y.tab.c p-exp.tmp -- "$(YACC)" $(YFLAGS)
 	-sed -e '/extern.*malloc/d' \
 	     -e '/extern.*realloc/d' \
 	     -e '/extern.*free/d' \
--- gdb/configure.in	2002-12-04 12:16:47.000000000 -0500
+++ gdb/configure.in	2002-12-04 23:18:08.000000000 -0500
@@ -472,7 +472,7 @@
 ac_cv_c_long_double=yes, ac_cv_c_long_double=no)])
 AC_MSG_RESULT($ac_cv_c_long_double)
 if test $ac_cv_c_long_double = yes; then
-  AC_DEFINE(HAVE_LONG_DOUBLE)
+  AC_DEFINE([HAVE_LONG_DOUBLE], [], [Define if the `long double' type works])
 fi
 
 dnl See if the compiler and runtime support printing long doubles
--- gdb/testsuite/gdb.hp/gdb.objdbg/configure.in	2002-12-04 12:17:00.000000000 -0500
+++ gdb/testsuite/gdb.hp/gdb.objdbg/configure.in	2002-12-04 23:18:08.000000000 -0500
@@ -11,6 +11,5 @@
 AC_SUBST(CC)
 AC_CONFIG_AUX_DIR(`cd $srcdir;pwd`/../../../..)
 AC_CANONICAL_SYSTEM
-AC_CONFIG_SUBDIRS(objdbg01 objdbg02 objdbg03 objdbg04)
 
 AC_OUTPUT(Makefile)
--- gprof/acinclude.m4	2002-12-04 12:17:02.000000000 -0500
+++ gprof/acinclude.m4	2002-12-04 23:18:08.000000000 -0500
@@ -1,12 +1,3 @@
-sinclude(../libtool.m4)
-dnl The lines below arrange for aclocal not to bring libtool.m4
-dnl AM_PROG_LIBTOOL into aclocal.m4, while still arranging for automake
-dnl to add a definition of LIBTOOL to Makefile.in.
-ifelse(yes,no,[
-AC_DEFUN([AM_PROG_LIBTOOL],)
-AC_SUBST(LIBTOOL)
-])
-
 sinclude(../gettext.m4)
 ifelse(yes,no,[
 AC_DEFUN([CY_WITH_NLS],)
--- ld/Makefile.am	2002-12-04 12:17:11.000000000 -0500
+++ ld/Makefile.am	2002-12-04 23:18:08.000000000 -0500
@@ -9,6 +9,8 @@
 
 tooldir = $(exec_prefix)/$(target_alias)
 
+YLWRAP = $(srcdir)/../ylwrap
+
 YACC = `if [ -f ../bison/bison ]; then echo ../bison/bison -y -L$(srcdir)/../bison/; else echo @YACC@; fi`
 YFLAGS = -d
 LEX = `if [ -f ../flex/flex ]; then echo ../flex/flex; else echo @LEX@; fi`
--- ld/acinclude.m4	2002-12-04 12:17:11.000000000 -0500
+++ ld/acinclude.m4	2002-12-04 23:18:08.000000000 -0500
@@ -1,14 +1,5 @@
 sinclude(../bfd/acinclude.m4)
 
-dnl sinclude(../libtool.m4) already included in bfd/acinclude.m4
-dnl The lines below arrange for aclocal not to bring libtool.m4
-dnl AM_PROG_LIBTOOL into aclocal.m4, while still arranging for automake
-dnl to add a definition of LIBTOOL to Makefile.in.
-ifelse(yes,no,[
-AC_DEFUN([AM_PROG_LIBTOOL],)
-AC_SUBST(LIBTOOL)
-])
-
 dnl sinclude(../gettext.m4) already included in bfd/acinclude.m4
 ifelse(yes,no,[
 AC_DEFUN([CY_WITH_NLS],)
--- libiberty/aclocal.m4	2002-12-04 12:17:23.000000000 -0500
+++ libiberty/aclocal.m4	2002-12-04 23:18:08.000000000 -0500
@@ -69,7 +69,7 @@
   ac_cv_func_strncmp_works=no)
 rm -f core core.* *.core])
 if test $ac_cv_func_strncmp_works = no ; then
-  LIBOBJS="$LIBOBJS strncmp.o"
+  AC_LIBOBJ(strncmp)
 fi
 ])
 
@@ -102,9 +102,10 @@
   test -z "$CC" && AC_MSG_ERROR([no acceptable cc found in \$PATH])
 fi
 
-AC_PROG_CC_GNU
+_AC_COMPILER_OBJEXT
+_AC_LANG_COMPILER_GNU
 
-if test $ac_cv_prog_gcc = yes; then
+if test $ac_compiler_gnu = yes; then
   GCC=yes
   ac_libiberty_warn_cflags='-W -Wall -Wtraditional -pedantic'
 dnl Check whether -g works, even if CFLAGS is set, in case the package
@@ -113,7 +114,7 @@
   ac_test_CFLAGS="${CFLAGS+set}"
   ac_save_CFLAGS="$CFLAGS"
   CFLAGS=
-  AC_PROG_CC_G
+  _AC_PROG_CC_G
   if test "$ac_test_CFLAGS" = set; then
     CFLAGS="$ac_save_CFLAGS"
   elif test $ac_cv_prog_cc_g = yes; then
--- libiberty/configure.in	2002-12-04 12:17:23.000000000 -0500
+++ libiberty/configure.in	2002-12-04 23:18:08.000000000 -0500
@@ -240,7 +240,12 @@
   # newlib provide and which ones we will be expected to provide.
 
   if test "x${with_newlib}" = "xyes"; then
-    LIBOBJS="asprintf.o basename.o insque.o random.o strdup.o vasprintf.o"
+    AC_LIBOBJ(asprintf)
+    AC_LIBOBJ(basename)
+    AC_LIBOBJ(insque)
+    AC_LIBOBJ(random)
+    AC_LIBOBJ(strdup)
+    AC_LIBOBJ(vasprintf)
 
     for f in $funcs; do
       case "$f" in
@@ -308,8 +313,16 @@
     # Handle VxWorks configuration specially, since on VxWorks the
     # libraries are actually on the target board, not in the file
     # system.
-    LIBOBJS="basename.o getpagesize.o insque.o random.o strcasecmp.o"
-    LIBOBJS="$LIBOBJS strncasecmp.o strdup.o vfork.o waitpid.o vasprintf.o"
+    AC_LIBOBJ(basename)
+    AC_LIBOBJ(getpagesize)
+    AC_LIBOBJ(insque)
+    AC_LIBOBJ(random)
+    AC_LIBOBJ(strcasecmp)
+    AC_LIBOBJ(strncasecmp)
+    AC_LIBOBJ(strdup)
+    AC_LIBOBJ(vfork)
+    AC_LIBOBJ(waitpid)
+    AC_LIBOBJ(vasprintf)
     for f in $funcs; do
       case "$f" in
 	basename | getpagesize | insque | random | strcasecmp)
@@ -356,7 +369,7 @@
     if test -n "${with_target_subdir}"
     then
       funcs="`echo $funcs | sed -e 's/random//'`"
-      LIBOBJS="$LIBOBJS random.o"
+      AC_LIBOBJ(random)
       vars="`echo $vars | sed -e 's/sys_siglist//'`"
       checkfuncs="`echo $checkfuncs | sed -e 's/strsignal//' -e 's/psignal//'`"
     fi
@@ -392,12 +405,12 @@
 
   # We haven't set the list of objects yet.  Use the standard autoconf
   # tests.  This will only work if the compiler works.
-  AC_PROG_CC_WORKS
+  AC_PROG_CC
   AC_REPLACE_FUNCS($funcs)
   libiberty_AC_FUNC_C_ALLOCA
   AC_FUNC_VFORK
   if test $ac_cv_func_vfork_works = no; then
-    LIBOBJS="$LIBOBJS vfork.o"
+    AC_LIBOBJ(vfork)
   fi
   # We only need _doprnt if we might use it to implement v*printf.
   if test $ac_cv_func_vprintf != yes \
--- opcodes/acinclude.m4	2002-12-04 12:17:45.000000000 -0500
+++ opcodes/acinclude.m4	2002-12-04 23:18:08.000000000 -0500
@@ -1,15 +1,5 @@
 sinclude(../bfd/acinclude.m4)
 
-dnl sinclude(../libtool.m4) already included in bfd/acinclude.m4
-dnl The lines below arrange for aclocal not to bring libtool.m4
-dnl AM_PROG_LIBTOOL into aclocal.m4, while still arranging for automake
-dnl to add a definition of LIBTOOL to Makefile.in.
-ifelse(yes,no,[
-AC_DEFUN([AM_PROG_LIBTOOL],)
-AC_DEFUN([AM_DISABLE_SHARED],)
-AC_SUBST(LIBTOOL)
-])
-
 dnl sinclude(../gettext.m4) already included in bfd/acinclude.m4
 ifelse(yes,no,[
 AC_DEFUN([CY_WITH_NLS],)
--- rda/configure.in	2002-12-04 12:17:46.000000000 -0500
+++ rda/configure.in	2002-12-04 23:18:08.000000000 -0500
@@ -7,7 +7,7 @@
 dnl automake support
 AM_MAINTAINER_MODE
 dnl AC_LIBTOOL_WIN32_DLL
-AM_PROG_LIBTOOL
+AC_PROG_LIBTOOL
 AC_EXEEXT
 AC_LANG_C
 
--- rda/lib/Makefile.am	2002-12-04 12:17:46.000000000 -0500
+++ rda/lib/Makefile.am	2002-12-04 23:18:08.000000000 -0500
@@ -9,7 +9,6 @@
 # Create a libtool convenience archive
 # ... and a plain library archive for non-libtool clients
 noinst_LTLIBRARIES = librda.la
-noinst_LIBRARIES = librda.a
 
 INCLUDES = -I$(srcdir) -I$(srcdir)/../include \
 	-I$(srcdir)/../../include
@@ -17,4 +16,3 @@
 THESOURCES=gdbserv-input.c gdbserv-output.c gdbserv-state.c gdbserv-utils.c gdbsocket.c gdblog.c stdio-log.c gdbserv-log.c gdbloop.c gdbsched.c gdbserv-target.c
 
 librda_la_SOURCES = $(THESOURCES)
-librda_a_SOURCES = $(THESOURCES)
--- rda/unix/configure.in	2002-12-04 12:17:47.000000000 -0500
+++ rda/unix/configure.in	2002-12-04 23:18:08.000000000 -0500
@@ -9,7 +9,7 @@
 
 dnl automake support
 AM_MAINTAINER_MODE
-AM_PROG_LIBTOOL
+AC_PROG_LIBTOOL
 AC_EXEEXT
 AC_LANG_C
 
@@ -32,43 +32,43 @@
 case "$target" in
   mips64*linux*)
     TARGET_MODULES="linux-target.o no-threads.o ptrace-target.o" 
-    AC_DEFINE(LINUX_TARGET)
-    AC_DEFINE(GREGSET_T,  prgregset_t)
-    AC_DEFINE(FPREGSET_T, prfpregset_t)
-    AC_DEFINE(HAVE_LWPID_T)
-    AC_DEFINE(HAVE_PSADDR_T)
-    AC_DEFINE(HAVE_PRGREGSET_T)
-    AC_DEFINE(HAVE_PRFPREGSET_T)
+    AC_DEFINE(LINUX_TARGET, [], [Define if target is any Linux])
+    AC_DEFINE(GREGSET_T, prgregset_t, [Define the type name of a gregset])
+    AC_DEFINE(FPREGSET_T, prfpregset_t, [Define the type name of an fpregset])
+    AC_DEFINE(HAVE_LWPID_T, [], [Define if system headers will define lwpid_t])
+    AC_DEFINE(HAVE_PSADDR_T, [], [Define if system headers will define psaddr_t])
+    AC_DEFINE(HAVE_PRGREGSET_T, [], [Define if system headers will define prgregset_t])
+    AC_DEFINE(HAVE_PRFPREGSET_T, [], [Define if system headers will define prfpregset_t])
     ;;
   i?86*linux* | \
   powerpc*linux* | \
   arm*linux* | \
   mips*linux*)
     TARGET_MODULES="linux-target.o thread-db.o ptrace-target.o" 
-    AC_DEFINE(LINUX_TARGET)
-    AC_DEFINE(GREGSET_T,  prgregset_t)
-    AC_DEFINE(FPREGSET_T, prfpregset_t)
-    AC_DEFINE(HAVE_LWPID_T)
-    AC_DEFINE(HAVE_PSADDR_T)
-    AC_DEFINE(HAVE_PRGREGSET_T)
-    AC_DEFINE(HAVE_PRFPREGSET_T)
+    AC_DEFINE(LINUX_TARGET, [], [Define if target is any Linux])
+    AC_DEFINE(GREGSET_T, prgregset_t, [Define the type name of a gregset])
+    AC_DEFINE(FPREGSET_T, prfpregset_t, [Define the type name of an fpregset])
+    AC_DEFINE(HAVE_LWPID_T, [], [Define if system headers will define lwpid_t])
+    AC_DEFINE(HAVE_PSADDR_T, [], [Define if system headers will define psaddr_t])
+    AC_DEFINE(HAVE_PRGREGSET_T, [], [Define if system headers will define prgregset_t])
+    AC_DEFINE(HAVE_PRFPREGSET_T, [], [Define if system headers will define prfpregset_t])
     ;;
   *linux*)
     TARGET_MODULES="linux-target.o no-threads.o ptrace-target.o" 
-    AC_DEFINE(LINUX_TARGET)
-    AC_DEFINE(GREGSET_T,  prgregset_t)
-    AC_DEFINE(FPREGSET_T, prfpregset_t)
-    AC_DEFINE(HAVE_LWPID_T)
-    AC_DEFINE(HAVE_PSADDR_T)
-    AC_DEFINE(HAVE_PRGREGSET_T)
-    AC_DEFINE(HAVE_PRFPREGSET_T)
+    AC_DEFINE(LINUX_TARGET, [], [Define if target is any Linux])
+    AC_DEFINE(GREGSET_T, prgregset_t, [Define the type name of a gregset])
+    AC_DEFINE(FPREGSET_T, prfpregset_t, [Define the type name of an fpregset])
+    AC_DEFINE(HAVE_LWPID_T, [], [Define if system headers will define lwpid_t])
+    AC_DEFINE(HAVE_PSADDR_T, [], [Define if system headers will define psaddr_t])
+    AC_DEFINE(HAVE_PRGREGSET_T, [], [Define if system headers will define prgregset_t])
+    AC_DEFINE(HAVE_PRFPREGSET_T, [], [Define if system headers will define prfpregset_t])
     ;;
   *solaris*)
     TARGET_MODULES="solaris-target.o dummy-target.o" 
-    AC_DEFINE(SOLARIS_TARGET)
-# Place-holders -- not necessarily correct...
-    AC_DEFINE(GREGSET_T,  gregset_t)
-    AC_DEFINE(FPREGSET_T, fpregset_t)
+    AC_DEFINE(SOLARIS_TARGET, [], [Define if target is any Solaris])
+    # Place-holders -- not necessarily correct...
+    AC_DEFINE(HAVE_PRGREGSET_T, [], [Define if system headers will define prgregset_t])
+    AC_DEFINE(HAVE_PRFPREGSET_T, [], [Define if system headers will define prfpregset_t])
     ;;
 esac
 
@@ -77,116 +77,116 @@
 case "$target" in
   *solaris*)
     dnl FIXME: differentiate between flavors of Solaris!
-    AC_DEFINE(SPARC32_SOLARIS_TARGET)
-    AC_DEFINE(PTRACE_XFER_SIZE, 4)
-    AC_DEFINE(PTRACE_XFER_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG1_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG2_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG3_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG4_TYPE_LONG)
+    AC_DEFINE(SPARC32_SOLARIS_TARGET, [], [Define is target is Sparc32])
+    AC_DEFINE(PTRACE_XFER_SIZE, 4, [Define for ptrace systems, to the size of a ptrace word.])
+    AC_DEFINE(PTRACE_XFER_TYPE_LONG, [], [Define if ptrace transfer type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG1_TYPE_LONG, [], [Define if ptrace arg1 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG2_TYPE_LONG, [], [Define if ptrace arg2 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG3_TYPE_LONG, [], [Define if ptrace arg3 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG4_TYPE_LONG, [], [Define if ptrace arg4 type is long or unsigned long.])
     ;;
   sh*linux*)
-    AC_DEFINE(SH_LINUX_TARGET)
-    AC_DEFINE(PTRACE_XFER_SIZE, 4)
-    AC_DEFINE(PTRACE_XFER_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG1_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG2_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG3_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG4_TYPE_LONG)
+    AC_DEFINE(SH_LINUX_TARGET, [], [Define if target is SH (3? 4?) Linux])
+    AC_DEFINE(PTRACE_XFER_SIZE, 4, [Define for ptrace systems, to the size of a ptrace word.])
+    AC_DEFINE(PTRACE_XFER_TYPE_LONG, [], [Define if ptrace transfer type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG1_TYPE_LONG, [], [Define if ptrace arg1 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG2_TYPE_LONG, [], [Define if ptrace arg2 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG3_TYPE_LONG, [], [Define if ptrace arg3 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG4_TYPE_LONG, [], [Define if ptrace arg4 type is long or unsigned long.])
     ;;
   mips64*linux*n64)
-    AC_DEFINE(MIPS64_LINUX_TARGET)
-    AC_DEFINE(MIPS_ABI_N64)
-    AC_DEFINE(PTRACE_XFER_SIZE, 8)
-    AC_DEFINE(PTRACE_XFER_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG1_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG2_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG3_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG4_TYPE_LONG)
+    AC_DEFINE(MIPS64_LINUX_TARGET, [], [Define if target is 64-bit MIPS Linux])
+    AC_DEFINE(MIPS_ABI_N64, [], [Define if target uses MIPS n64 ABI])
+    AC_DEFINE(PTRACE_XFER_SIZE, 8, [Define for ptrace systems, to the size of a ptrace word.])
+    AC_DEFINE(PTRACE_XFER_TYPE_LONG_LONG, [], [Define if ptrace transfer type is long long or unsigned long long.])
+    AC_DEFINE(PTRACE_ARG1_TYPE_LONG_LONG, [], [Define if ptrace arg1 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG2_TYPE_LONG_LONG, [], [Define if ptrace arg2 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG3_TYPE_LONG_LONG, [], [Define if ptrace arg3 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG4_TYPE_LONG_LONG, [], [Define if ptrace arg4 type is long or unsigned long.])
     ;;
   mips64*linux*n32)
-    AC_DEFINE(MIPS64_LINUX_TARGET)
-    AC_DEFINE(MIPS_ABI_N32)
-    AC_DEFINE(PTRACE_XFER_SIZE, 8)
-    AC_DEFINE(PTRACE_XFER_TYPE_LONG_LONG)
-    AC_DEFINE(PTRACE_ARG1_TYPE_LONG_LONG)
-    AC_DEFINE(PTRACE_ARG2_TYPE_LONG_LONG)
-    AC_DEFINE(PTRACE_ARG3_TYPE_LONG_LONG)
-    AC_DEFINE(PTRACE_ARG4_TYPE_LONG_LONG)
+    AC_DEFINE(MIPS64_LINUX_TARGET, [], [Define if target is 64-bit MIPS Linux])
+    AC_DEFINE(MIPS_ABI_N32, [], [Define if target uses MIPS n32 ABI])
+    AC_DEFINE(PTRACE_XFER_SIZE, 8, [Define for ptrace systems, to the size of a ptrace word.])
+    AC_DEFINE(PTRACE_XFER_TYPE_LONG_LONG, [], [Define if ptrace transfer type is long long or unsigned long long.])
+    AC_DEFINE(PTRACE_ARG1_TYPE_LONG_LONG, [], [Define if ptrace arg1 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG2_TYPE_LONG_LONG, [], [Define if ptrace arg2 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG3_TYPE_LONG_LONG, [], [Define if ptrace arg3 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG4_TYPE_LONG_LONG, [], [Define if ptrace arg4 type is long or unsigned long.])
     ;;
   mips64*linux*o32)
-    AC_DEFINE(MIPS64_LINUX_TARGET)
-    AC_DEFINE(MIPS_ABI_O32)
-    AC_DEFINE(PTRACE_XFER_SIZE, 4)
-    AC_DEFINE(PTRACE_XFER_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG1_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG2_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG3_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG4_TYPE_LONG)
+    AC_DEFINE(MIPS64_LINUX_TARGET, [], [Define if target is 64-bit MIPS Linux])
+    AC_DEFINE(MIPS_ABI_O32, [], [Define if target uses MIPS o32 ABI])
+    AC_DEFINE(PTRACE_XFER_SIZE, 4, [Define for ptrace systems, to the size of a ptrace word.])
+    AC_DEFINE(PTRACE_XFER_TYPE_LONG, [], [Define if ptrace transfer type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG1_TYPE_LONG, [], [Define if ptrace arg1 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG2_TYPE_LONG, [], [Define if ptrace arg2 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG3_TYPE_LONG, [], [Define if ptrace arg3 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG4_TYPE_LONG, [], [Define if ptrace arg4 type is long or unsigned long.])
     ;;
   mips*linux*)
-    AC_DEFINE(MIPS_LINUX_TARGET)
-    AC_DEFINE(MIPS_ABI_O32)
-    AC_DEFINE(PTRACE_XFER_SIZE, 4)
-    AC_DEFINE(PTRACE_XFER_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG1_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG2_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG3_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG4_TYPE_LONG)
+    AC_DEFINE(MIPS_LINUX_TARGET, [], [Define if target is (32-bit) MIPS Linux])
+    AC_DEFINE(MIPS_ABI_O32, [], [Define if target uses MIPS o32 ABI])
+    AC_DEFINE(PTRACE_XFER_SIZE, 4, [Define for ptrace systems, to the size of a ptrace word.])
+    AC_DEFINE(PTRACE_XFER_TYPE_LONG, [], [Define if ptrace transfer type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG1_TYPE_LONG, [], [Define if ptrace arg1 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG2_TYPE_LONG, [], [Define if ptrace arg2 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG3_TYPE_LONG, [], [Define if ptrace arg3 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG4_TYPE_LONG, [], [Define if ptrace arg4 type is long or unsigned long.])
     ;;
   i?86*linux*)
-    AC_DEFINE(X86_LINUX_TARGET)
-    AC_DEFINE(PTRACE_XFER_SIZE, 4)
-    AC_DEFINE(PTRACE_XFER_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG1_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG2_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG3_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG4_TYPE_LONG)
+    AC_DEFINE(X86_LINUX_TARGET, [], [Define if target is x86 Linux])
+    AC_DEFINE(PTRACE_XFER_SIZE, 4, [Define for ptrace systems, to the size of a ptrace word.])
+    AC_DEFINE(PTRACE_XFER_TYPE_LONG, [], [Define if ptrace transfer type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG1_TYPE_LONG, [], [Define if ptrace arg1 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG2_TYPE_LONG, [], [Define if ptrace arg2 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG3_TYPE_LONG, [], [Define if ptrace arg3 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG4_TYPE_LONG, [], [Define if ptrace arg4 type is long or unsigned long.])
     ;;
   powerpc*linux*)
-    AC_DEFINE(PPC_LINUX_TARGET)
-    AC_DEFINE(PTRACE_XFER_SIZE, 4)
-    AC_DEFINE(PTRACE_XFER_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG1_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG2_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG3_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG4_TYPE_LONG)
+    AC_DEFINE(PPC_LINUX_TARGET, [], [Define if target is powerpc Linux])
+    AC_DEFINE(PTRACE_XFER_SIZE, 4, [Define for ptrace systems, to the size of a ptrace word.])
+    AC_DEFINE(PTRACE_XFER_TYPE_LONG, [], [Define if ptrace transfer type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG1_TYPE_LONG, [], [Define if ptrace arg1 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG2_TYPE_LONG, [], [Define if ptrace arg2 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG3_TYPE_LONG, [], [Define if ptrace arg3 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG4_TYPE_LONG, [], [Define if ptrace arg4 type is long or unsigned long.])
     ;;
   m68k*linux*)
-    AC_DEFINE(M68K_LINUX_TARGET)
-    AC_DEFINE(PTRACE_XFER_SIZE, 4)
-    AC_DEFINE(PTRACE_XFER_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG1_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG2_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG3_TYPE_LONG)
-    AC_DEFINE(PTRACE_ARG4_TYPE_LONG)
+    AC_DEFINE(M68K_LINUX_TARGET, [], [Define if target is m68k Linux])
+    AC_DEFINE(PTRACE_XFER_SIZE, 4, [Define for ptrace systems, to the size of a ptrace word.])
+    AC_DEFINE(PTRACE_XFER_TYPE_LONG, [], [Define if ptrace transfer type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG1_TYPE_LONG, [], [Define if ptrace arg1 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG2_TYPE_LONG, [], [Define if ptrace arg2 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG3_TYPE_LONG, [], [Define if ptrace arg3 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG4_TYPE_LONG, [], [Define if ptrace arg4 type is long or unsigned long.])
     ;;
   alpha*linux*)
-    AC_DEFINE(ALPHA_LINUX_TARGET)
-    AC_DEFINE(PTRACE_XFER_SIZE, 8)
-    AC_DEFINE(PTRACE_XFER_TYPE_LONG_LONG)
-    AC_DEFINE(PTRACE_ARG1_TYPE_LONG_LONG)
-    AC_DEFINE(PTRACE_ARG2_TYPE_LONG_LONG)
-    AC_DEFINE(PTRACE_ARG3_TYPE_LONG_LONG)
-    AC_DEFINE(PTRACE_ARG4_TYPE_LONG_LONG)
+    AC_DEFINE(ALPHA_LINUX_TARGET, [], [Define if target is alpha Linux])
+    AC_DEFINE(PTRACE_XFER_SIZE, 8, [Define for ptrace systems, to the size of a ptrace word.])
+    AC_DEFINE(PTRACE_XFER_TYPE_LONG_LONG, [], [Define if ptrace transfer type is long long or unsigned long long.])
+    AC_DEFINE(PTRACE_ARG1_TYPE_LONG_LONG, [], [Define if ptrace arg1 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG2_TYPE_LONG_LONG, [], [Define if ptrace arg2 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG3_TYPE_LONG_LONG, [], [Define if ptrace arg3 type is long or unsigned long.])
+    AC_DEFINE(PTRACE_ARG4_TYPE_LONG_LONG, [], [Define if ptrace arg4 type is long or unsigned long.])
     ;;
   arm*linux*)
 	if test "$arm32" = "yes"; then
-	    AC_DEFINE(ARM_LINUX_TARGET)
-    	    AC_DEFINE(PTRACE_XFER_SIZE, 4)
-    	    AC_DEFINE(PTRACE_XFER_TYPE_LONG)
-    	    AC_DEFINE(PTRACE_ARG1_TYPE_LONG)
-      	    AC_DEFINE(PTRACE_ARG2_TYPE_LONG)
-    	    AC_DEFINE(PTRACE_ARG3_TYPE_LONG)
-    	    AC_DEFINE(PTRACE_ARG4_TYPE_LONG)
+	    AC_DEFINE(ARM_LINUX_TARGET, [], [Define if target is arm Linux])
+	    AC_DEFINE(PTRACE_XFER_SIZE, 4, [Define for ptrace systems, to the size of a ptrace word.])
+	    AC_DEFINE(PTRACE_XFER_TYPE_LONG, [], [Define if ptrace transfer type is long or unsigned long.])
+	    AC_DEFINE(PTRACE_ARG1_TYPE_LONG, [], [Define if ptrace arg1 type is long or unsigned long.])
+	    AC_DEFINE(PTRACE_ARG2_TYPE_LONG, [], [Define if ptrace arg2 type is long or unsigned long.])
+	    AC_DEFINE(PTRACE_ARG3_TYPE_LONG, [], [Define if ptrace arg3 type is long or unsigned long.])
+	    AC_DEFINE(PTRACE_ARG4_TYPE_LONG, [], [Define if ptrace arg4 type is long or unsigned long.])
 	else
-    	    AC_DEFINE(ARM_LINUX_TARGET)
-    	    AC_DEFINE(PTRACE_XFER_SIZE, 8)
-    	    AC_DEFINE(PTRACE_XFER_TYPE_LONG_LONG)
-    	    AC_DEFINE(PTRACE_ARG1_TYPE_LONG_LONG)
-    	    AC_DEFINE(PTRACE_ARG2_TYPE_LONG_LONG)
-    	    AC_DEFINE(PTRACE_ARG3_TYPE_LONG_LONG)
-    	    AC_DEFINE(PTRACE_ARG4_TYPE_LONG_LONG)
+    	    AC_DEFINE(ARM_LINUX_TARGET, [], [Define if target is arm Linux])
+    	    AC_DEFINE(PTRACE_XFER_SIZE, 8, [Define for ptrace systems, to the size of a ptrace word.])
+	    AC_DEFINE(PTRACE_XFER_TYPE_LONG_LONG, [], [Define if ptrace transfer type is long long or unsigned long long.])
+	    AC_DEFINE(PTRACE_ARG1_TYPE_LONG_LONG, [], [Define if ptrace arg1 type is long or unsigned long.])
+	    AC_DEFINE(PTRACE_ARG2_TYPE_LONG_LONG, [], [Define if ptrace arg2 type is long or unsigned long.])
+	    AC_DEFINE(PTRACE_ARG3_TYPE_LONG_LONG, [], [Define if ptrace arg3 type is long or unsigned long.])
+	    AC_DEFINE(PTRACE_ARG4_TYPE_LONG_LONG, [], [Define if ptrace arg4 type is long or unsigned long.])
 	fi
 	;;
 esac
--- rda/win32/configure.in	2002-12-04 12:17:47.000000000 -0500
+++ rda/win32/configure.in	2002-12-04 23:18:08.000000000 -0500
@@ -24,14 +24,10 @@
 case "$target" in
   *cygwin*)
     dnl FIXME: differentiate between flavors of Solaris!
-    AC_DEFINE(WIN32_TARGET)
+    AC_DEFINE(WIN32_TARGET, [], [Define if target is Win32])
     ;;
 esac
 
-if test -f /usr/include/foo.h; then
-  AC_DEFINE(HAVE_AC_DEFINE, 1, [define if have AC_DEFINE])
-fi
-
 dnl Outputs
 AC_OUTPUT(Makefile)
 
--- sim/common/aclocal.m4	2002-12-04 12:17:54.000000000 -0500
+++ sim/common/aclocal.m4	2002-12-04 23:18:08.000000000 -0500
@@ -904,7 +904,7 @@
 
     dnl If we use NLS figure out what method
     if test "$USE_NLS" = "yes"; then
-      AC_DEFINE(ENABLE_NLS)
+      AC_DEFINE(ENABLE_NLS, 1, [Define to 1 if NLS is requested])
       AC_MSG_CHECKING([whether included gettext is requested])
       AC_ARG_WITH(included-gettext,
         [  --with-included-gettext use the GNU gettext library included here],
@@ -938,7 +938,8 @@
 
 	   if test "$gt_cv_func_gettext_libc" = "yes" \
 	      || test "$gt_cv_func_gettext_libintl" = "yes"; then
-	      AC_DEFINE(HAVE_GETTEXT)
+	      AC_DEFINE(HAVE_GETTEXT, 1,
+			[Define as 1 if you have gettext and don't want to use GNU gettext.])
 	      AM_PATH_PROG_WITH_TEST(MSGFMT, msgfmt,
 		[test -z "`$ac_dir/$ac_word -h 2>&1 | grep 'dv '`"], no)dnl
 	      if test "$MSGFMT" != "no"; then
@@ -1217,7 +1218,8 @@
       [AC_TRY_LINK([#include <locale.h>], [return LC_MESSAGES],
        am_cv_val_LC_MESSAGES=yes, am_cv_val_LC_MESSAGES=no)])
     if test $am_cv_val_LC_MESSAGES = yes; then
-      AC_DEFINE(HAVE_LC_MESSAGES)
+      AC_DEFINE(HAVE_LC_MESSAGES, 1,
+		[Define if your locale.h file contains LC_MESSAGES.])
     fi
   fi])
 

[-- Attachment #5: build.sh --]
[-- Type: application/octet-stream, Size: 246 bytes --]

#! /bin/sh

set -e

src=$1

$src/configure

dirs="bfd binutils gas gdb gprof ld libiberty mmalloc opcodes rda sim utils"
for i in $dirs; do
    rm -f config.cache
    (cd $i && $src/$i/configure --enable-maintainer-mode)
done

rm -f config.cache

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Klee Dienes]

On Thursday, December 5, 2002, at 06:19 PM, Alan Modra wrote:

> On Thu, Dec 05, 2002 at 02:55:38PM -0800, Ian Lance Taylor wrote:
>> Perhaps --enable-maintainer-mode could be extended to specify a PATH
>> to use to find the tools.
>
> It would need to be on a per-directory basis.  Something like
>
> --enable-maintainer-mode=\
> "gdb:/usr/local/000227/bin,libstdc++-v3:/usr/local/oldauto/bin,*:yes"

What if the rules generated by --enable-maintainer-mode were to pass a 
version number to each of the tools when using them to re-generate 
files?  The version number passed would be the same version number used 
to generate the existing version of the generated files.  Then the 
autotools could either dispatch to the correct version of the tool 
based on the version number, or
perhaps generate an error if the version numbers did not match.  In 
order to upgrade the generated files in a directory to a newer version, 
the user would have to explicitly run autoreconf or run he appropriate 
autotools directly.

This would make it a lot harder for a maintainer to accidentally use 
the wrong version of an autotool when regenerating files in a 
directory.  It would also make it possible to write a top-level script 
that would explicitly re-generate all of the files in a tree with 
explicitly specified versions (or at least verify that the versions 
being used were correct).

Regardless of how we choose to do it, though, I think it's important 
that maintainers be able to update individual subdirectories to newer 
versions of the autotools independently of each other (even if the way 
we choose to do that is to say "don't run global 
--enable-maintainer-mode, and be aware of the versions of the autotools 
you are using").  If we don't, the bar for updating versions of 
autotools is just too high.  Trying to coordinate a simultaneous 
upgrade of even a simple change across the combined src+gcc repository 
is a huge amount of work --- if that's the only way to do upgrades, it 
seems much more likely that the upgrades will tend to not get done.  
The thought of even *touching* sid is daunting to me, much less the 
thought of trying to claim that I've changed all of its Makefiles and 
understand the changes.

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Zack Weinberg]

Alexandre Oliva <aoliva@redhat.com> writes:

> On Dec  5, 2002, Zack Weinberg <zack@codesourcery.com> wrote:
>
>> AC_NO_EXECUTABLES has two effects: (1) it disables the equivalent of
>> AC_PROG_CC_WORKS, which is what we need.  But, (2) it causes autoconf
>> to barf if an AC_TRY_LINK test appears anywhere in the script being
>> generated.
>
> Please tell me why (2) doesn't make sense.
>
> If AC_PROG_CC_WORKS can't even link a do-nothing program, how would
> you expect to get any useful results from AC_TRY_LINK?

Because libstdc++'s AC_TRY_LINK tests are only executed in a situation
where AC_PROG_CC_WORKS would have succeeded (i.e. a native compilation).

zw

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Alexandre Oliva]

On Dec  5, 2002, Zack Weinberg <zack@codesourcery.com> wrote:

> AC_NO_EXECUTABLES has two effects: (1) it disables the equivalent of
> AC_PROG_CC_WORKS, which is what we need.  But, (2) it causes autoconf
> to barf if an AC_TRY_LINK test appears anywhere in the script being
> generated.

Please tell me why (2) doesn't make sense.

If AC_PROG_CC_WORKS can't even link a do-nothing program, how would
you expect to get any useful results from AC_TRY_LINK?

> libstdc++-v3/configure.in has lots of AC_TRY_LINK tests.

If we know AC_PROG_CC_WORKS fails, it is a mistake to use AC_TRY_LINK
tests.  Removing the constraint from autoconf will do us no good.

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

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Tom Tromey]

>>>>> "Zack" == Zack Weinberg <zack@codesourcery.com> writes:

Zack> Someone on the autoconf team knew about this and tried to help out by
Zack> providing an undocumented macro called AC_NO_EXECUTABLES:

Zack> # FIXME: The GCC team has specific needs which the current Autoconf
Zack> # framework cannot solve elegantly.  This macro implements a dirty
Zack> # hack until Autoconf is abble to provide the services its users
Zack> # needs.

Zack> They are only executed in a native compilation, but that's not good
Zack> enough for AC_NO_EXECUTABLES.

Presumably if AC_NO_EXECUTABLES exists solely for the use of gcc, then
it could be changed to do what gcc actually requires.

Tom

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Maciej W. Rozycki]

On Thu, 5 Dec 2002, Nathanael Nerode wrote:

> It was mentioned that autoconf2.5 scripts will have trouble with 
> building because of the top level passing down --target unconditionally.
> 
> Unfortunately I think some other aspects of the configure scripts 
> require --target to be passed down unconditionally. :-/  Otherwise I'd 
> just change it.

 Well, at least ${tooldir} requires to be set properly (that's typically
${exec_prefix}/${target_alias}) and currently it is done by passing
--target which sets ${target_alias}.  However it may be possible to set
${tooldir} based on ${host_alias} or even ${build_alias}, as ${*_alias}
variables are empty if not set by a user.  I think the order should be:

if test "x${target_alias}" != x; then
	# Cross-tools
	tooldir = '${exec_prefix}'/${target_alias}
elif test "x${host_alias}" != x; then
	# Native tools for a different host
	tooldir = '${exec_prefix}'/${host_alias}
elif test "x${build_alias}" != x; then
	# Native tools using an explicit alias
	tooldir = '${exec_prefix}'/${build_alias}
else
	# Native tools using a default alias
	tooldir = '${exec_prefix}'/${build}
fi

And then only pass these of --build, --host, --target to subdirectories
which have their respective ${*_alias} variable set.  Obviously
${program_prefix} should either only be set if ${target_alias} is not
empty or use the above outline, too. 

 I'll check if the approach works for me -- anyone interested is invited
to do that, too.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Zack Weinberg]

Alan Modra <amodra@bigpond.net.au> writes:
>
> The trouble with this idea is that older autoconf and automake aren't
> installed as $tool-$version, and last I checked, current autoconf
> doesn't install with a version suffix.  Old tools really need to be
> installed with a different --prefix.  Hmm, I suppose a few symbolic
> links would cure that problem.  What happens if you need three three
> or four different versions of autoconf?

Debian has a clever wrapper script (in the autoconf2.13 package) that
causes configure to get regenerated using 2.13 unless there's an
AC_PREREQ(2.5x) line in configure.in, or configure.in is named
configure.ac.

But I think that we really just ought to get the transition done,
assuming that it is in fact possible.

zw

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Alan Modra]

On Thu, Dec 05, 2002 at 03:45:52PM -0800, Mike Stump wrote:
> On Thursday, December 5, 2002, at 03:19 PM, Alan Modra wrote:
> >On Thu, Dec 05, 2002 at 02:55:38PM -0800, Ian Lance Taylor wrote:
> >>Perhaps --enable-maintainer-mode could be extended to specify a PATH
> >>to use to find the tools.
> >
> >It would need to be on a per-directory basis.  Something like
> >
> >--enable-maintainer-mode=\
> >"gdb:/usr/local/000227/bin,libstdc++-v3:/usr/local/oldauto/bin,*:yes"
> 
> This is beyond gross.  :-(

Sniff.  I'm sure I could make it a lot more gross.  :)

> Better to require
> 
> autoconf-2.14
> autoconf
> 
> and then have each directory know which one to use, and require the 
> advanced user to have these.
> 
> OAUTOCONF = autoconf-2.14
> AUTOCONF = autoconf
> 
> and then use $(AUTOCONF) for new uses, and $(OAUTOCONF) for old uses.
> 
> Also, we need a version check on the old autoconf to be sure that it 
> isn't too new.

The trouble with this idea is that older autoconf and automake aren't
installed as $tool-$version, and last I checked, current autoconf
doesn't install with a version suffix.  Old tools really need to be
installed with a different --prefix.  Hmm, I suppose a few symbolic
links would cure that problem.  What happens if you need three three
or four different versions of autoconf?

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Andrew Cagney]

> 
> Yes, I suppose that would be required to support a single
> --enable-maintainer-mode at the top level.
> 
> On the other hand, I personally usually run a basic configure at the
> top level, and then run configure again in the subdirectories for
> which I want to use --enable-maintainer-mode.

So _thats_ how to avoids maintainer mode on all but one directory...

Andrew

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Mike Stump]

On Thursday, December 5, 2002, at 03:19 PM, Alan Modra wrote:
> On Thu, Dec 05, 2002 at 02:55:38PM -0800, Ian Lance Taylor wrote:
>> Perhaps --enable-maintainer-mode could be extended to specify a PATH
>> to use to find the tools.
>
> It would need to be on a per-directory basis.  Something like
>
> --enable-maintainer-mode=\
> "gdb:/usr/local/000227/bin,libstdc++-v3:/usr/local/oldauto/bin,*:yes"

This is beyond gross.  :-(

Better to require

autoconf-2.14
autoconf

and then have each directory know which one to use, and require the 
advanced user to have these.

OAUTOCONF = autoconf-2.14
AUTOCONF = autoconf

and then use $(AUTOCONF) for new uses, and $(OAUTOCONF) for old uses.

Also, we need a version check on the old autoconf to be sure that it 
isn't too new.

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Ian Lance Taylor]

Alan Modra <amodra@bigpond.net.au> writes:

> On Thu, Dec 05, 2002 at 02:55:38PM -0800, Ian Lance Taylor wrote:
> > Perhaps --enable-maintainer-mode could be extended to specify a PATH
> > to use to find the tools.
> 
> It would need to be on a per-directory basis.  Something like
> 
> --enable-maintainer-mode=\
> "gdb:/usr/local/000227/bin,libstdc++-v3:/usr/local/oldauto/bin,*:yes"

Yes, I suppose that would be required to support a single
--enable-maintainer-mode at the top level.

On the other hand, I personally usually run a basic configure at the
top level, and then run configure again in the subdirectories for
which I want to use --enable-maintainer-mode.

Ian

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Alan Modra]

On Thu, Dec 05, 2002 at 02:55:38PM -0800, Ian Lance Taylor wrote:
> Perhaps --enable-maintainer-mode could be extended to specify a PATH
> to use to find the tools.

It would need to be on a per-directory basis.  Something like

--enable-maintainer-mode=\
"gdb:/usr/local/000227/bin,libstdc++-v3:/usr/local/oldauto/bin,*:yes"

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Zack Weinberg]

Nathanael Nerode <neroden@twcny.rr.com> writes:

>>I'd like to remind everyone involved that last I checked it was flat
>>impossible to do what libstdc++-v3/configure.in needs to do, using
>>autoconf 2.5x.  I am not particularly sanguine about the situation
>
> Flat impossible?
>
> Wow.

Like I said, I'd be delighted to be proved wrong.

> I'd be interested to hear more about the problem.  Why can't it be
> dealt with by using private macros?

It was a couple years ago, but I think I still remember pretty
clearly.

First off, you've probably met this stuff (from libstdc++/aclocal.m4):

  # Never versions of autoconf add an underscore to these functions.
  # Prevent future problems ...
  ifdef([AC_PROG_CC_G],[],[define([AC_PROG_CC_G],defn([_AC_PROG_CC_G]))])
  ifdef([AC_PROG_CC_GNU],[],[define([AC_PROG_CC_GNU],defn([_AC_PROG_CC_GNU]))])
  ifdef([AC_PROG_CXX_G],[],[define([AC_PROG_CXX_G],defn([_AC_PROG_CXX_G]))])
  ifdef([AC_PROG_CXX_GNU],[],[define([AC_PROG_CXX_GNU],defn([_AC_PROG_CXX_GNU]))])

  # AC_PROG_CC
  # FIXME: We temporarily define our own version of AC_PROG_CC.  This is
  # copied from autoconf 2.12, but does not call AC_PROG_CC_WORKS.  We
  # are probably using a cross compiler, which will not be able to fully
  # link an executable.  This is addressed in later versions of autoconf.

  AC_DEFUN(LIB_AC_PROG_CC,
  [AC_BEFORE([$0], [AC_PROG_CPP])dnl
  dnl Fool anybody using AC_PROG_CC.
  AC_PROVIDE([AC_PROG_CC])
  AC_CHECK_PROG(CC, gcc, gcc)
  if test -z "$CC"; then
    AC_CHECK_PROG(CC, cc, cc, , , /usr/ucb/cc)
    test -z "$CC" && AC_MSG_ERROR([no acceptable cc found in \$PATH])
  fi

  AC_PROG_CC_GNU

  if test $ac_cv_prog_gcc = yes; then
    GCC=yes
  dnl Check whether -g works, even if CFLAGS is set, in case the package
  dnl plays around with CFLAGS (such as to build both debugging and
  dnl normal versions of a library), tasteless as that idea is.
    ac_test_CFLAGS="${CFLAGS+set}"
    ac_save_CFLAGS="$CFLAGS"
    CFLAGS=
    AC_PROG_CC_G
    if test "$ac_test_CFLAGS" = set; then
      CFLAGS="$ac_save_CFLAGS"
    elif test $ac_cv_prog_cc_g = yes; then
      CFLAGS="-g -O2"
    else
      CFLAGS="-O2"
    fi
  else
    GCC=
    test "${CFLAGS+set}" = set || CFLAGS="-g"
  fi
  ])

This is a clone of the 2.13 AC_PROG_CC with some minor modifications:
specifically, the AC_PROG_CC_WORKS call was removed.  With autoconf
2.50+, the internal structure of AC_PROG_CC is totally different, and
this definition breaks.  (The "newer versions of autoconf" stuff was
someone's attempt to fix it, but it doesn't work.)

Someone on the autoconf team knew about this and tried to help out by
providing an undocumented macro called AC_NO_EXECUTABLES:

# AC_NO_EXECUTABLES
# -----------------
# FIXME: The GCC team has specific needs which the current Autoconf
# framework cannot solve elegantly.  This macro implements a dirty
# hack until Autoconf is abble to provide the services its users
# needs.
#
# Several of the support libraries that are often built with GCC can't
# assume the tool-chain is already capable of linking a program: the
# compiler often expects to be able to link with some of such
# libraries.
#
# In several of these libraries, workarounds have been introduced to
# avoid the AC_PROG_CC_WORKS test, that would just abort their
# configuration.  The introduction of AC_EXEEXT, enabled either by
# libtool or by CVS autoconf, have just made matters worse.
AC_DEFUN_ONCE([AC_NO_EXECUTABLES],
[m4_divert_push([KILL])

AC_BEFORE([$0], [_AC_COMPILER_EXEEXT_WORKS])
AC_BEFORE([$0], [_AC_COMPILER_EXEEXT])

m4_define([_AC_COMPILER_EXEEXT_WORKS],
[cross_compiling=maybe
])

m4_define([_AC_COMPILER_EXEEXT],
[EXEEXT=
])

m4_define([AC_LINK_IFELSE],
[AC_FATAL([All the tests involving linking were disabled by $0])])

m4_divert_pop()dnl
])# AC_NO_EXECUTABLES

(lang.m4 from autoconf 2.56)

AC_NO_EXECUTABLES has two effects: (1) it disables the equivalent of
AC_PROG_CC_WORKS, which is what we need.  But, (2) it causes autoconf
to barf if an AC_TRY_LINK test appears anywhere in the script being
generated.  libstdc++-v3/configure.in has lots of AC_TRY_LINK tests.
They are only executed in a native compilation, but that's not good
enough for AC_NO_EXECUTABLES.

Going over it all again, I realize that we could probably just
redefine AC_NO_EXECUTABLES to do what we want.  We'd have to
specialize its definition for every version of autoconf that we cared
about, and check at every new release that it hadn't broken, but it
would work.  I guess it's not impossible after all.

zw

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Ian Lance Taylor]

Alan Modra <amodra@bigpond.net.au> writes:

> I'm concerned that this proposal may be raising the bar too high.
> How long has it been since some poor fool^H^H^H^H^H^H^H^H^Hbrave soul
> attempted to modernize binutils configury?

It's only been a bit over five years since I reworked binutils
configury to use automake and libtool.

I guess it was about two years before that that Ken Raeburn and I
changed the binutils to use autoconf.

I'm sure I don't know why autoconf 2.5 is not called autoconf 3.
Still, switching to autoconf 2.5 is surely a smaller change than
either of those.

It should be easy enough to extend AC_PREREQ a bit to make sure that
people use the correct version of autoconf for the directory in
question.

Perhaps --enable-maintainer-mode could be extended to specify a PATH
to use to find the tools.

Ian

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Joern Rennecke]

> It seems that the major impact of configuring parts of a tree using
> different autoconf versions will be on people using
> --enable-maintainer-mode, so another solution might be to extend
> --enable-maintainer-mode to accept a list of directories.  I suspect
> most developers will only want --enable-maintainer-mode in the
> particular area they work on.

Unfortunately, for CPU port maintainers the area they work on is a
cross-section of gcc, newlib, binutils and gdb.

-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Nathanael Nerode]

>I'd like to remind everyone involved that last I checked it was flat
>impossible to do what libstdc++-v3/configure.in needs to do, using
>autoconf 2.5x.  I am not particularly sanguine about the situation

Flat impossible?

Wow.

And for the top level, all I had to do was define my own entire set of
macros to replace the AC_CHECK_TOOL and AC_PROG_* collection. :-)

I'd be interested to hear more about the problem.  Why can't it be dealt 
with by using private macros?

--Nathanael

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Alan Modra]

On Thu, Dec 05, 2002 at 01:31:52PM -0800, Zack Weinberg wrote:
> But I do see a way forward.  It goes like this.  One directory at a
> time, we go through and do whatever it takes to get that directory's
> configure.in to work properly with both 2.13 and 2.5x, independent of
> what version of autoconf was used to generate configure in other
> directories.  This may involve submitting patches to the autoconf
> maintainers.  Whoever volunteers to do this must be willing to
> maintain these scripts in that state indefinitely -- I did it for the
> gcc subdirectory a year or so ago and I discovered a couple weeks back
> that it had mysteriously broken.

I'm concerned that this proposal may be raising the bar too high.
How long has it been since some poor fool^H^H^H^H^H^H^H^H^Hbrave soul
attempted to modernize binutils configury?

It seems that the major impact of configuring parts of a tree using
different autoconf versions will be on people using
--enable-maintainer-mode, so another solution might be to extend
--enable-maintainer-mode to accept a list of directories.  I suspect
most developers will only want --enable-maintainer-mode in the
particular area they work on.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Christopher Faylor]

On Thu, Dec 05, 2002 at 02:07:28PM -0500, Nathanael Nerode wrote:
>Can you please work up a patch for gcc 3.4 to update
>boehm-gc fastjar gcc libf2c libffi libiberty libjava libobjc 
>libstdc++-v3 zlib
>
>And a patch for Insight
>itcl libgui
>
>And one for Dejagnu
>dejagnu expect
>
>And for Newlib & Cygwin
>libgloss newlib winsup

Remember that any changes to configury in newlib or cygwin *require
approval*.  Please don't just check in changes in these directories.
CVS commit permission in gdb or binutils does not imply permission for
cygwin, newlib, or most of the other directories in the 'src'
repository.

cgf

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Zack Weinberg]

Nathanael Nerode <neroden@twcny.rr.com> writes:

> Accordingly, I suggest getting clean patches for small sets of 
> directories, making sure they work, getting them reviewed, and then 
> putting them in; and then starting on the next set.  Keep sending update
> notices to the various lists regarding which directories use the 'new' 
> tools and which use the 'old'.  If you can make scripts which work 
> correctly under *both* autoconf 2.5x *and* autoconf 2.13, by all means 
> do so *first*, and mark those scripts as "compatibile with both", of 
> course; but I expect that will only happen for the simplest directories.

I'd like to remind everyone involved that last I checked it was flat
impossible to do what libstdc++-v3/configure.in needs to do, using
autoconf 2.5x.  I am not particularly sanguine about the situation
having changed, since it involved the undocumented AC_NO_EXECUTABLES
macro that as far as I know nobody but us has a use for -- and we're
not using it, because it doesn't do what we need it to do.  Until that
is resolved, which will involve submitting patches to autoconf,
getting them accepted upstream, and waiting for a release, gcc
*cannot* move to autoconf 2.5x.  We are not being stick-in-the-muds
because we want to.

(Please, I beg of you, prove me wrong about this problem.)

I am concerned about the prospect of having the src repository update
to 2.5x while the gcc repository is still stuck with 2.13.  Having
different parts of the combined tree need different versions of
autotools is a recipe for disaster.

But I do see a way forward.  It goes like this.  One directory at a
time, we go through and do whatever it takes to get that directory's
configure.in to work properly with both 2.13 and 2.5x, independent of
what version of autoconf was used to generate configure in other
directories.  This may involve submitting patches to the autoconf
maintainers.  Whoever volunteers to do this must be willing to
maintain these scripts in that state indefinitely -- I did it for the
gcc subdirectory a year or so ago and I discovered a couple weeks back
that it had mysteriously broken.

Once the entire tree makes it into this state, we have a flag day
where we bump AC_PREREQ and regenerate everything.  And only then can
we start using 2.5x specific features in configure scripts.

As for libtool and automake, my suggestion is, as usual, that both
should be eradicated from the face of the Earth; as this proposal is
probably a non-starter, I decline to discuss what to do with them any
further.

zw

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Andrew Cagney]

> I really would like to see the tree using autoconf 2.5x as soon as 
> possible; if this can be done before I autoconfiscate the top level 
> (which is not autoconfiscated yet) it will save me an awful lot of 
> trouble, since I can then use autoconf 2.5x for that autoconfiscation. 
> :-/
> 
> Your patch as is updates
> bfd binutils gas gdb gprof ld mmalloc opcodes rda sim utils
> 
> Can you please work up a patch for gcc 3.4 to update
> boehm-gc fastjar gcc libf2c libffi libiberty libjava libobjc 
> libstdc++-v3 zlib

Just a step back here.  Some of the directories listed below belong to 
the FSF, but some don't.  I don't think anyone can be asking Klee to 
update non FSF code.  That's why I asked Klee to drop RDA from the 
original list.

> And a patch for Insight
> itcl libgui
> 
> And one for Dejagnu
> dejagnu expect

> And for Newlib & Cygwin
> libgloss newlib winsup
> 
> And one for
> sid
> 
> and one for
> intl
> 
> --
> However, I think that it's OK to update one directory at a time, 
> provided we specify clearly what's going on, and get it all done before 
> the next release of anything.

I don't think we can guarentee that, but I think we can live with the 
consequences :-/

> Accordingly, I suggest getting clean patches for small sets of 
> directories, making sure they work, getting them reviewed, and then 
> putting them in; and then starting on the next set.  Keep sending update
> notices to the various lists regarding which directories use the 'new' 
> tools and which use the 'old'.  If you can make scripts which work 
> correctly under *both* autoconf 2.5x *and* autoconf 2.13, by all means 
> do so *first*, and mark those scripts as "compatibile with both", of 
> course; but I expect that will only happen for the simplest directories.
> 
> If this is acceptable to other people in the various groups of course.
> 
> I expect this will generate a certain amount of breakage, but then so 
> did my changes.  In both cases, it needs to be done, we just have to 
> make sure all the breakage gets fixed.

Andrew

> --Nathanael
> 
> P.S.
> It was mentioned that autoconf2.5 scripts will have trouble with 
> building because of the top level passing down --target unconditionally.
> 
> Unfortunately I think some other aspects of the configure scripts 
> require --target to be passed down unconditionally. :-/  Otherwise I'd 
> just change it.
> 
> 
> 

Re: [RFC] Update to current automake/autoconf/libtool versions.

[Nathanael Nerode]

>1.  Please make sure to coordinate with Nathanael Nerode, who is in the
>middle of extensive autoconf-related work in the GCC repository.

I really would like to see the tree using autoconf 2.5x as soon as 
possible; if this can be done before I autoconfiscate the top level 
(which is not autoconfiscated yet) it will save me an awful lot of 
trouble, since I can then use autoconf 2.5x for that autoconfiscation. 
:-/

Your patch as is updates
bfd binutils gas gdb gprof ld mmalloc opcodes rda sim utils

Can you please work up a patch for gcc 3.4 to update
boehm-gc fastjar gcc libf2c libffi libiberty libjava libobjc 
libstdc++-v3 zlib

And a patch for Insight
itcl libgui

And one for Dejagnu
dejagnu expect

And for Newlib & Cygwin
libgloss newlib winsup

And one for
sid

and one for
intl

--
However, I think that it's OK to update one directory at a time, 
provided we specify clearly what's going on, and get it all done before 
the next release of anything.

Accordingly, I suggest getting clean patches for small sets of 
directories, making sure they work, getting them reviewed, and then 
putting them in; and then starting on the next set.  Keep sending update
notices to the various lists regarding which directories use the 'new' 
tools and which use the 'old'.  If you can make scripts which work 
correctly under *both* autoconf 2.5x *and* autoconf 2.13, by all means 
do so *first*, and mark those scripts as "compatibile with both", of 
course; but I expect that will only happen for the simplest directories.

If this is acceptable to other people in the various groups of course.

I expect this will generate a certain amount of breakage, but then so 
did my changes.  In both cases, it needs to be done, we just have to 
make sure all the breakage gets fixed.

--Nathanael

P.S.
It was mentioned that autoconf2.5 scripts will have trouble with 
building because of the top level passing down --target unconditionally.

Unfortunately I think some other aspects of the configure scripts 
require --target to be passed down unconditionally. :-/  Otherwise I'd 
just change it.