[RFA/PATCH] Darwin fixes for ltconfig, ltcf-c.sh

[RFA/PATCH] Darwin fixes for ltconfig, ltcf-c.sh

[Klee Dienes]

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

The enclosed patch fixes the Darwin support in the top-level libtool 
support files of the binutils and GDB source repository.  For the most 
part it just adds more Darwin-specific config blocks to ltconfig and 
ltcf-c.sh, and fixes a couple of nits in the existing Darwin support.

The only non-Darwin-specific patch is the change to default 
CONFIG_SHELL to /bin/sh in ltconfig ... this prevents ltconfig from 
silently setting max_cmd_len to "none" if CONFIG_SHELL is not passed to 
ltconfig.


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

         * ltconfig: Default CONFIG_SHELL to /bin/sh if no value is 
passed in
         by the environment.  Recognize "macos10" as specifying a
         Darwin-based system.  Remove extra '$' in library_names_spec 
for the
         Darwin configuration.
         * ltcf-c.sh: Move the Darwin config-block from the 
"$with_gnu_ld =
         yes" section to the "$with_gnu_ld = no" section (Darwin doesn't 
use
         GNU ld as it's linker).  Use ac_cv_prog_cc_pic to set pic 
flags, not
         lt_cv_prog_cc_pic.  Add a Darwin block for pic flags when using 
GCC
         as well as when using the system compiler.  Recognize "macos10" 
as
         specifying a Darwin-based system in all clauses.



[-- Attachment #2: ltconfig.txt --]
[-- Type: text/plain, Size: 4838 bytes --]

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

	* ltconfig: Default CONFIG_SHELL to /bin/sh if no value is passed in
	by the environment.  Recognize "macos10" as specifying a
	Darwin-based system.  Remove extra '$' in library_names_spec for the
	Darwin configuration.
	* ltcf-c.sh: Move the Darwin config-block from the "$with_gnu_ld =
	yes" section to the "$with_gnu_ld = no" section (Darwin doesn't use
	GNU ld as it's linker).  Use ac_cv_prog_cc_pic to set pic flags, not
	lt_cv_prog_cc_pic.  Add a Darwin block for pic flags when using GCC
	as well as when using the system compiler.  Recognize "macos10" as
	specifying a Darwin-based system in all clauses.
	
diff -u --exclude=CVS --exclude=Makefile --exclude=configure cygnus.cygnus/src/./ltcf-c.sh cygnus.current/src/./ltcf-c.sh
--- cygnus.cygnus/src/./ltcf-c.sh	Tue Jul 30 13:32:54 2002
+++ cygnus.current/src/./ltcf-c.sh	Wed Oct 30 21:53:09 2002
@@ -175,16 +175,6 @@
       $CC $output_objdir/$soname-exp '$lt_cv_cc_dll_switch' -Wl,-e,'$dll_entry' -o $output_objdir/$soname '$ltdll_obj'$libobjs $deplibs $compiler_flags'
     ;;
 
-  darwin* | rhapsody*)
-    allow_undefined_flag='-undefined suppress'
-    archive_cmds='$CC `test .$module = .yes && echo -bundle || echo -dynamiclib` $allow_undefined_flag -o $lib $libobjs $deplibs $linkopts -install_name $rpath/$soname `test -n "$verstring" -a x$verstring != x0.0 && echo $verstring`'
-    # We need to add '_' to the symbols in $export_symbols first
-    #archive_expsym_cmds="$archive_cmds"' && strip -s $export_symbols'
-    hardcode_direct=yes
-    hardcode_shlibpath_var=no
-    whole_archive_flag_spec='-all_load $convenience'
-    ;;
-
   netbsd*)
     if echo __ELF__ | $CC -E - | grep __ELF__ >/dev/null; then
       archive_cmds='$LD -Bshareable $libobjs $deplibs $linker_flags -o $lib'
@@ -456,6 +446,16 @@
     link_all_deplibs=yes
     ;;
 
+  darwin* | rhapsody* | macos10*)
+    allow_undefined_flag='-undefined error'
+    archive_cmds='$CC `test .$module = .yes && echo -bundle || echo -dynamiclib` $allow_undefined_flag -o $lib $libobjs $deplibs $linkopts -install_name $rpath/$soname `test -n "$verstring" -a x"$verstring" != x0.0 && echo "$verstring"`'
+    # We need to add '_' to the symbols in $export_symbols first
+    #archive_expsym_cmds="$archive_cmds"' && strip -s $export_symbols'
+    hardcode_direct=yes
+    hardcode_shlibpath_var=no
+    whole_archive_flag_spec='-all_load $convenience'
+    ;;
+
   netbsd*)
     if echo __ELF__ | $CC -E - | grep __ELF__ >/dev/null; then
       archive_cmds='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags'  # a.out
@@ -667,10 +667,10 @@
       # built for inclusion in a dll (and should export symbols for example).
       ac_cv_prog_cc_pic='-DDLL_EXPORT'
       ;;
-    darwin* | rhapsody*)
+    darwin* | rhapsody* | macos10*)
       # PIC is the default on this platform
       # Common symbols not allowed in MH_DYLIB files
-      lt_cv_prog_cc_pic='-fno-common'
+      ac_cv_prog_cc_pic='-fno-common'
       ;;
     *djgpp*)
       # DJGPP does not support shared libraries at all
@@ -710,6 +710,12 @@
       # This hack is so that the source file can tell whether it is being
       # built for inclusion in a dll (and should export symbols for example).
       ac_cv_prog_cc_pic='-DDLL_EXPORT'
+      ;;
+
+    darwin* | rhapsody* | macos10*)
+      # PIC is the default on this platform
+      # Common symbols not allowed in MH_DYLIB files
+      ac_cv_prog_cc_pic='-fno-common'
       ;;
 
     newsos6)
diff -u --exclude=CVS --exclude=Makefile --exclude=configure cygnus.cygnus/src/./ltconfig cygnus.current/src/./ltconfig
--- cygnus.cygnus/src/./ltconfig	Tue Jul 30 13:33:02 2002
+++ cygnus.current/src/./ltconfig	Wed Oct 30 21:53:10 2002
@@ -27,6 +27,7 @@
 # A lot of this script is taken from autoconf-2.10.
 
 # Check that we are running under the correct shell.
+CONFIG_SHELL=${CONFIG_SHELL-/bin/sh}
 SHELL=${CONFIG_SHELL-/bin/sh}
 echo=echo
 if test "X$1" = X--no-reexec; then
@@ -1100,12 +1101,12 @@
   lt_cv_dlopen_libs=
   ;;
 
-darwin* | rhapsody*)
+darwin* | rhapsody* | macos10*)
   dynamic_linker="$host_os dyld"
   version_type=darwin
   need_lib_prefix=no
   need_version=no
-  library_names_spec='${libname}${release}${versuffix}.`test .$module = .yes && echo so || echo dylib` ${libname}${release}${major}.$`test .$module = .yes && echo so || echo dylib` ${libname}.`test .$module = .yes && echo so || echo dylib`'
+  library_names_spec='${libname}${release}${versuffix}.`test .$module = .yes && echo so || echo dylib` ${libname}${release}${major}.`test .$module = .yes && echo so || echo dylib` ${libname}.`test .$module = .yes && echo so || echo dylib`'
   soname_spec='${libname}${release}${major}.`test .$module = .yes && echo so || echo dylib`'
   shlibpath_overrides_runpath=yes
   shlibpath_var=DYLD_LIBRARY_PATH

Re: [RFA/PATCH] Darwin fixes for ltconfig, ltcf-c.sh

[Andrew Cagney]

These files are part of libtool.  From src/MAINTAINERS.

Andrew

ltconfig; ltmain.sh
         libtool: http://gnu.org
         Changes need to be done in tandem with the official LIBTOOL
         sources or submitted to the master file maintainer and brought
         in via a merge.

Re: [RFA/PATCH] Darwin fixes for ltconfig, ltcf-c.sh

[Klee Dienes]

I believe libtool-1.4.3 already has correct Darwin support, although I 
haven't done overly much testing with it.

I submitted a patch to the current GDB/binutils libtool because it was 
unclear when the next libtool merge might be, because I didn't want to 
get in the way of the folks doing the autoconfiscation work, and 
because there was existing precedent (see the ChangeLog entries for 
2002-01-27 and 2001-11-13, for example).

I'm certainly willing to try to push through an upgrade of the 
GDB/binutils libtool to 1.4.3 if that's what's necessary, though; let 
me know and I'll put together a patch.

On Wednesday, November 13, 2002, at 12:57 PM, Andrew Cagney wrote:

> These files are part of libtool.  From src/MAINTAINERS.
>
> Andrew
>
> ltconfig; ltmain.sh
>         libtool: http://gnu.org
>         Changes need to be done in tandem with the official LIBTOOL
>         sources or submitted to the master file maintainer and brought
>         in via a merge.

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

[Klee Dienes]

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

The following patch updates the following directories to use the latest 
versions of libtool, autoconf, and automake:

bfd binutils gas gdb gprof ld libiberty mmalloc opcodes rda sim utils

ltmain.sh (GNU libtool) 1.4.3
autoconf (GNU Autoconf) 2.56
automake (GNU automake) 1.7.1
gettext (GNU gettext) 0.11.5

To apply the patch, I put the following four files in a directory, and 
ran 'files.sh' in the top-level directory of the GDB/Binutils tree, 
then configured and built with 'build.sh' (the script was necessary in 
order to pass --enable-maintainer-mode to only the subdirectories for 
which it was appropriate).  I then did a full build to verify that 
maintainer-mode was working, and used the files generated by 
--enable-maintainer-mode as the final versions.  I'm not including the 
ChangeLog entries for all of the auto-generated files, as they're not 
overly interesting; I plan to generate them with a perl script based on 
the result of the build.  I'm also not including the diffs to the 
generated files, since they were about 6Mb, and not all that 
interesting.  I'm happy to provide either if requested.


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

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

	* .cvsignore: Add autom4te.cache.

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.
	* configure: Pass --build=$host_alias to sub-makes if no other
	value is specified.
		
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: bfd.txt --]
[-- Type: text/plain, Size: 32188 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
--- 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
--- configure	2002-12-02 23:55:04.000000000 -0500
+++ configure	2002-12-04 23:18:08.000000000 -0500
@@ -1473,6 +1473,10 @@
 
 ### The recursion line is here.
 			if [ ! -z "${recprog}" ] ; then
+				if [ -z "$buildopt" ]
+				then
+					buildopt="--build=$host_alias"
+				fi
 	                        if eval ${config_shell} ${recprog} ${verbose} ${buildopt} --host=${host_alias} --target=${tgt_alias} \
         	                        ${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
--- 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 #4: files.sh --]
[-- Type: application/octet-stream, Size: 1167 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 #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

[-- Attachment #6: Type: text/plain, Size: 1080 bytes --]





On Wednesday, November 13, 2002, at 01:32 PM, Klee Dienes wrote:

> I believe libtool-1.4.3 already has correct Darwin support, although I 
> haven't done overly much testing with it.
>
> I submitted a patch to the current GDB/binutils libtool because it was 
> unclear when the next libtool merge might be, because I didn't want to 
> get in the way of the folks doing the autoconfiscation work, and 
> because there was existing precedent (see the ChangeLog entries for 
> 2002-01-27 and 2001-11-13, for example).
>
> I'm certainly willing to try to push through an upgrade of the 
> GDB/binutils libtool to 1.4.3 if that's what's necessary, though; let 
> me know and I'll put together a patch.
>
> On Wednesday, November 13, 2002, at 12:57 PM, Andrew Cagney wrote:
>
>> These files are part of libtool.  From src/MAINTAINERS.
>>
>> Andrew
>>
>> ltconfig; ltmain.sh
>>         libtool: http://gnu.org
>>         Changes need to be done in tandem with the official LIBTOOL
>>         sources or submitted to the master file maintainer and brought
>>         in via a merge.

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

[Hans-Peter Nilsson]

On Thu, 5 Dec 2002, Klee Dienes wrote:
> The following patch updates the following directories to use the latest
> versions of libtool, autoconf, and automake:

Bravo!  Great!  ... Could you please do this for GCC
gcc-3_4-basic-improvements-branch too?

Thanks!

brgds, H-P

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

[Andrew Cagney]

Er, wow!  Few technical hurdles to overcome first.

Anyone know what happens if only half the directories get converted?

There is a problem with libiberty and utils because GCC have their feet 
stuck in the ice (unless src, again splits off from GCC, but I suspect 
here we don't want to).

> bfd binutils gas gdb gprof ld libiberty mmalloc opcodes rda sim utils

bfd, binutils, gas, gprof, ld and opcodes are all BINUTILS.
mmalloc, sim and gdb are all GDB.
I'd drop rda from the list.

I don't understand this:

- 
$(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)

isn't it independant of the switch?

Same with this?

-  AC_DEFINE(HAVE_LONG_DOUBLE)
+  AC_DEFINE([HAVE_LONG_DOUBLE], [], [Define if the `long double' type 
works])

(or did the new autoconf change the interface causing a warning if the 
three parameters were not present?).

Andrew

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

[Maciej W. Rozycki]

On Thu, 5 Dec 2002, Klee Dienes wrote:

> The following patch updates the following directories to use the latest 
> versions of libtool, autoconf, and automake:
> 
> bfd binutils gas gdb gprof ld libiberty mmalloc opcodes rda sim utils
> 
> ltmain.sh (GNU libtool) 1.4.3
> autoconf (GNU Autoconf) 2.56
> automake (GNU automake) 1.7.1
> gettext (GNU gettext) 0.11.5

 Does it work for both native and cross builds?  Last time I checked,
autoconf 2.5x considered all binutils builds are for cross tools because
of the --target option set unconditionally by the top-level configure and
as a result prefixed all tool names with $target_alias upon install.  The
patch doesn't seem to deal with it. 

 Otherwise -- nice work, thanks. 

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

[Daniel Jacobowitz]

On Thu, Dec 05, 2002 at 01:04:33AM -0500, Klee Dienes wrote:
> The following patch updates the following directories to use the latest 
> versions of libtool, autoconf, and automake:
> 
> bfd binutils gas gdb gprof ld libiberty mmalloc opcodes rda sim utils
> 
> ltmain.sh (GNU libtool) 1.4.3
> autoconf (GNU Autoconf) 2.56
> automake (GNU automake) 1.7.1
> gettext (GNU gettext) 0.11.5
> 
> To apply the patch, I put the following four files in a directory, and 
> ran 'files.sh' in the top-level directory of the GDB/Binutils tree, 
> then configured and built with 'build.sh' (the script was necessary in 
> order to pass --enable-maintainer-mode to only the subdirectories for 
> which it was appropriate).  I then did a full build to verify that 
> maintainer-mode was working, and used the files generated by 
> --enable-maintainer-mode as the final versions.  I'm not including the 
> ChangeLog entries for all of the auto-generated files, as they're not 
> overly interesting; I plan to generate them with a perl script based on 
> the result of the build.  I'm also not including the diffs to the 
> generated files, since they were about 6Mb, and not all that 
> interesting.  I'm happy to provide either if requested.
> 

Modulo other people's concerns, I pretty much like it.  I've got two of
my own though.

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

2.  I'd really, really like it if we had tarballs of the _exact_
version of all four autotools up on sources.redhat.com, and we required
(requested) all maintainers to download and use exactly those versions
when regenerating things.  That makes it vaguely possible to hand-check
configure diffs.  Red Hat and Debian ship slightly different versions
of autoconf 2.13...



-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Klee Dienes]

On Thursday, December 5, 2002, at 10:43 AM, Andrew Cagney wrote:

> I don't understand this:
>
> - $(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)
>
> isn't it independant of the switch?

It's a result of using the ylwrap from autoconf-1.7, which is needed 
since the rules for the binutils/ parsers are automatically generated 
by automake.

> Same with this?
>
> -  AC_DEFINE(HAVE_LONG_DOUBLE)
> +  AC_DEFINE([HAVE_LONG_DOUBLE], [], [Define if the `long double' type 
> works])
>
> (or did the new autoconf change the interface causing a warning if the 
> three parameters were not present?).

Not even a warning: it blows out autoheader with an error.  The new 
AC_DEFINE interface deprecates the use of a template file, and instead 
requires all the information to be provided by the AC_DEFINE commands 
(it's particularly annoying since the warning about the existence of a 
template file is about 10 lines long, ALL CAPS, and can't be turned off 
with --warnings=none).

I actually made a point of not fixing any warnings during the 
conversion that weren't symptoms of real errors.  My reasoning is that 
once the flag day part of the conversion is done, we can fix the 
warnings in individual directories individually, but that for the 
initial conversion it was best to keep it as simple as possible.

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

[DJ Delorie]

> There is a problem with libiberty and utils because GCC have their
> feet stuck in the ice

Plus the libiberty master *is* gcc, so you can't apply the patches to
just the src side anyway.  The libiberty in src is a "mere copy" of
the one in gcc.  You must apply libiberty patches to gcc either at the
same time or before applying them to src (and now is a bad time to
change gcc's libiberty).

Utils is not part of gcc.

> (unless src, again splits off from GCC, but I suspect here we don't
> want to).

Sorry, won't happen for libiberty.

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

[DJ Delorie]

> 2.  I'd really, really like it if we had tarballs of the _exact_
> version of all four autotools up on sources.redhat.com,

They're in ftp://sources.redhat.com/pub/binutils/ already.  Have been
for years.

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

[Daniel Jacobowitz]

On Thu, Dec 05, 2002 at 11:29:45AM -0500, DJ Delorie wrote:
> 
> > 2.  I'd really, really like it if we had tarballs of the _exact_
> > version of all four autotools up on sources.redhat.com,
> 
> They're in ftp://sources.redhat.com/pub/binutils/ already.  Have been
> for years.

Let me rephrase that in two parts:
 - keep them updated with the new ones
 - be more enthusiastic about recommending people use them.  Most do
   not.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[DJ Delorie]

> > > 2.  I'd really, really like it if we had tarballs of the _exact_
> > > version of all four autotools up on sources.redhat.com,
> > 
> > They're in ftp://sources.redhat.com/pub/binutils/ already.  Have been
> > for years.
> 
> Let me rephrase that in two parts:
>  - keep them updated with the new ones
>  - be more enthusiastic about recommending people use them.  Most do
>    not.

Hey, I didn't say it was perfect ;-)

I suppose we could rig up some auto-autoconf-commit script that just
did the right thing whenever configure.in's are committed.

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

[Maciej W. Rozycki]

On Thu, 5 Dec 2002, Daniel Jacobowitz wrote:

> > They're in ftp://sources.redhat.com/pub/binutils/ already.  Have been
> > for years.
> 
> Let me rephrase that in two parts:
>  - keep them updated with the new ones
>  - be more enthusiastic about recommending people use them.  Most do
>    not.

 Too bad special versions are required at all.  It's a major PITA to keep
specific versions for various packages

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

[Daniel Jacobowitz]

On Thu, Dec 05, 2002 at 05:39:54PM +0100, Maciej W. Rozycki wrote:
> On Thu, 5 Dec 2002, Daniel Jacobowitz wrote:
> 
> > > They're in ftp://sources.redhat.com/pub/binutils/ already.  Have been
> > > for years.
> > 
> > Let me rephrase that in two parts:
> >  - keep them updated with the new ones
> >  - be more enthusiastic about recommending people use them.  Most do
> >    not.
> 
>  Too bad special versions are required at all.  It's a major PITA to keep
> specific versions for various packages

It's not that they're special - it's that they're _consistent_ that
matters.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Klee Dienes]

Ah, indeed it does.  I had tested a cross-build, but didn't think to 
test 'make install' on the completed build.  I'll take a look, thanks.

On Thursday, December 5, 2002, at 10:44 AM, Maciej W. Rozycki wrote:

> Does it work for both native and cross builds?  Last time I checked,
> autoconf 2.5x considered all binutils builds are for cross tools 
> because
> of the --target option set unconditionally by the top-level configure 
> and
> as a result prefixed all tool names with $target_alias upon install.  
> The
> patch doesn't seem to deal with it.
>
>  Otherwise -- nice work, thanks.

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

[Andrew Cagney]

> On Thursday, December 5, 2002, at 10:43 AM, Andrew Cagney wrote:
> 
>> I don't understand this:
>> 
>> - $(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)
>> 
>> isn't it independant of the switch?

> 
> It's a result of using the ylwrap from autoconf-1.7, which is needed since the rules for the binutils/ parsers are automatically generated by automake.

Does it work now?

>> Same with this?
>> 
>> -  AC_DEFINE(HAVE_LONG_DOUBLE)
>> +  AC_DEFINE([HAVE_LONG_DOUBLE], [], [Define if the `long double' type works])
>> 
>> (or did the new autoconf change the interface causing a warning if the three parameters were not present?). 

> Not even a warning: it blows out autoheader with an error.  The new AC_DEFINE interface deprecates the use of a template file, and instead requires all the information to be provided by the AC_DEFINE commands (it's particularly annoying since the warning about the existence of a template file is about 10 lines long, ALL CAPS, and can't be turned off with --warnings=none).
> 

Ulgh.  Same here though, does this work with autoconf 2.13++ (the 
current offical autoconf)?

Andrew

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

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Thu, Dec 05, 2002 at 05:39:54PM +0100, Maciej W. Rozycki wrote:
 > > On Thu, 5 Dec 2002, Daniel Jacobowitz wrote:
 > > 
 > > > > They're in ftp://sources.redhat.com/pub/binutils/ already.  Have been
 > > > > for years.
 > > > 
 > > > Let me rephrase that in two parts:
 > > >  - keep them updated with the new ones
 > > >  - be more enthusiastic about recommending people use them.  Most do
 > > >    not.
 > > 
 > >  Too bad special versions are required at all.  It's a major PITA to keep
 > > specific versions for various packages
 > 
 > It's not that they're special - it's that they're _consistent_ that
 > matters.
 > 


Can a note with a link be added to the 'contribute' gdb page?
I, for instance,  keep loosing the reference.

Elena


 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer

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

[H. J. Lu]

On Thu, Dec 05, 2002 at 10:43:13AM -0500, Andrew Cagney wrote:
> Er, wow!  Few technical hurdles to overcome first.
> 
> Anyone know what happens if only half the directories get converted?
> 
> There is a problem with libiberty and utils because GCC have their feet 
> stuck in the ice (unless src, again splits off from GCC, but I suspect 
> here we don't want to).
> 

That is my major concern. I have toolchain setups of gcc 2.96 + the
current binutils, gcc 3.2 + the current binutils, gcc 3.2-redhat-8 +
the current binutils and gcc 3.3 + the current binutils. Will they
ever work together?



H.J.

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

[Klee Dienes]

As far as I can tell offhand, none of the other patches depend on 
libiberty being updated, so one option is to upgrade the other 
directories, and leave libiberty alone.

The downside of this is that gcc/binutils folks now need to keep 
multiple versions of the tools around, and I imagine it would play hell 
with --enable-maintainer-mode.

In what way is it a bad time to change libiberty?  I'm not arguing with 
the statement, just trying to understand the constraints a bit better.  
Would it be possible to convert the libiberty on the bib-branch, and 
import the binutils/gdb version from there?


On Thursday, December 5, 2002, at 11:28 AM, DJ Delorie wrote:

>
>> There is a problem with libiberty and utils because GCC have their
>> feet stuck in the ice
>
> Plus the libiberty master *is* gcc, so you can't apply the patches to
> just the src side anyway.  The libiberty in src is a "mere copy" of
> the one in gcc.  You must apply libiberty patches to gcc either at the
> same time or before applying them to src (and now is a bad time to
> change gcc's libiberty).
>
> Utils is not part of gcc.
>
>> (unless src, again splits off from GCC, but I suspect here we don't
>> want to).
>
> Sorry, won't happen for libiberty.
>

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

[DJ Delorie]

> As far as I can tell offhand, none of the other patches depend on
> libiberty being updated, so one option is to upgrade the other
> directories, and leave libiberty alone.

That would be fine.  If you had a patch that depended on libiberty
being upgraded, I'd probably question it anyway.

> The downside of this is that gcc/binutils folks now need to keep
> multiple versions of the tools around, and I imagine it would play
> hell with --enable-maintainer-mode.

You didn't propose changing gcc, newlib, cygwin, sid, or many other
projects, so this will be an issue regardless.

> In what way is it a bad time to change libiberty?

GCC is getting ready to branch for a release.  After the branch, we'll
merge bib and be back to the usual openness.

> Would it be possible to convert the libiberty on the bib-branch, and
> import the binutils/gdb version from there?

By the time the issues are worked out for gdb/binutils and the switch
made there, gcc will hopefully have branched.  Plus the gcc head is
more stable than the branch anyway, which is what I'd prefer be the
main copy for everyone else.

How much of a hurry are you in, anyway?

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

[Klee Dienes]

I actually found the files in ftp://sources.redhat.com/pub/binutils to 
be an impediment to using the correct versions.  For a long time I had 
no idea they even existed, and then once I found out about them, it was 
even more confusing, since they weren't the versions that were actually 
used.

I'd argue that we should:

1) Specify the versions of autoconf/automake/libtool/gettext by 
reference to official tarballs from ftp.gnu.org.  In general, define 
the version used to be "the most recent officially released version of 
each tool".

and either

2a) Consider updates to generated files caused by re-configuring with 
the most recent released version of the tools as an "obvious fix".

or (even better)

2b) Configure the CVS repository to run autoreconf using the most 
recent versions whenever a new configure.in/Makefile.in/Makefile.am is 
committed.

The idea here is that it's relatively straightforward for a 
binutils/gdb maintainer to know what to do when updating a 
configuration file (get the most recent version of the tools from the 
FSF and use them), and that we have a natural tendency to stay 
up-to-date with automake/autoconf changes, without having flag-day 
style upgrades become an issue.

On Thu, Dec 05, 2002 at 05:39:54PM +0100, Maciej W. Rozycki wrote:

> They're in ftp://sources.redhat.com/pub/binutils/ already.  Have been
> for years.

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

[Maciej W. Rozycki]

On Thu, 5 Dec 2002, Klee Dienes wrote:

> The idea here is that it's relatively straightforward for a 
> binutils/gdb maintainer to know what to do when updating a 
> configuration file (get the most recent version of the tools from the 
> FSF and use them), and that we have a natural tendency to stay 
> up-to-date with automake/autoconf changes, without having flag-day 
> style upgrades become an issue.

 That would be the most acceptable approach to me.  Of the tools involved,
only autoconf changed significantly recently with its transition from 2.13
to 2.50.  But versions 2.5x are around long enough now to get more or less
stabilized, so hesitating from going forward and making an upgrade can
only impede development.

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

[Klee Dienes]

My primary interest in all of this is to fully merge the Apple 
Binutils/GDB sources into the FSF tree, which requires some changes to 
libtool that are only in more recent versions of libtool/autoconf.

My secondary interest is that I seem to spend a lot of time hacking 
Binutils/GDB makefiles, and I'd like that process to be as painless as 
possible.

I'm in a moderate hurry for the gdb/binutils changes, mainly because 
Apple needs to have some form of the changes to enable the FSF sources 
to build properly on our platform, and I find the mental load of 
maintaining the divergent sources to be a headache, particularly when 
preparing patches.

I'm in no particular hurry for the libiberty changes, since it doesn't 
use libtool anyway and the current build setup works fine for Apple in 
the short-term.  I eventually hope to libtool-ize libiberty as well, 
but that can certainly wait until an appropriate time in the GCC 
release cycle.

On Thursday, December 5, 2002, at 12:42 PM, DJ Delorie wrote:
>
> By the time the issues are worked out for gdb/binutils and the switch
> made there, gcc will hopefully have branched.  Plus the gcc head is
> more stable than the branch anyway, which is what I'd prefer be the
> main copy for everyone else.
>
> How much of a hurry are you in, anyway?

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

[Andrew Cagney]

> I actually found the files in ftp://sources.redhat.com/pub/binutils to be an impediment to using the correct versions.  For a long time I had no idea they even existed, and then once I found out about them, it was even more confusing, since they weren't the versions that were actually used.

As a maintainer you should bring peoples attention to the fact that they 
used the wrong autoconf the moment you notice it.

> I'd argue that we should:
> 
> 1) Specify the versions of autoconf/automake/libtool/gettext by reference to official tarballs from ftp.gnu.org.  In general, define the version used to be "the most recent officially released version of each tool".

Reality check.  If the offical autoconf has a bug, GDB and BINUTILS will 
be forced to use a local version :-/

> and either
> 
> 2a) Consider updates to generated files caused by re-configuring with the most recent released version of the tools as an "obvious fix".

This is already the case.  However, it doesn't address the problem of an 
erant maintainer.

> or (even better)
> 
> 2b) Configure the CVS repository to run autoreconf using the most recent versions whenever a new configure.in/Makefile.in/Makefile.am is committed.

No.  That discussion was considered for GDB and indent.  Here the 
problem is in maintainers being able to follow a procedure.  Not a need 
for a new tool.

> The idea here is that it's relatively straightforward for a binutils/gdb maintainer to know what to do when updating a configuration file (get the most recent version of the tools from the FSF and use them), and that we have a natural tendency to stay up-to-date with automake/autoconf changes, without having flag-day style upgrades become an issue.

Andrew

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

[Doug Evans]

Klee Dienes writes:
 > I'd argue that we should:
 > 
 > 1) Specify the versions of autoconf/automake/libtool/gettext by 
 > reference to official tarballs from ftp.gnu.org.

This places a requirement on the maintainers of ftp.gnu.org
to not delete said tarballs until binutils has been updated.
I dont' think you or they want that kind of coupling.
Better to uncouple things and have your own tarballs.
Then you can upgrade according to your schedule, not theirs.

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

[Klee Dienes]

As long as the versions of the tools are specified by a version string 
referencing an official version in README-maintainer-mode, and not by 
"whatever version is on sourceware.cygnus.com", I'm happy.

In practice I can't imagine there would be a problem with versions 
disappearing from the FSF site before we had upgraded to the current 
version (the current autoconf repository has versions of autoconf going 
back to 1996).   But if that's a concern, we can always replicate 
official FSF releases to a local directory and cache them there.

On Thursday, December 5, 2002, at 01:58 PM, Doug Evans wrote:

> Klee Dienes writes:
>> I'd argue that we should:
>>
>> 1) Specify the versions of autoconf/automake/libtool/gettext by
>> reference to official tarballs from ftp.gnu.org.
>
> This places a requirement on the maintainers of ftp.gnu.org
> to not delete said tarballs until binutils has been updated.
> I dont' think you or they want that kind of coupling.
> Better to uncouple things and have your own tarballs.
> Then you can upgrade according to your schedule, not theirs.

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

[Ian Lance Taylor]

Klee Dienes <klee@apple.com> writes:

> As long as the versions of the tools are specified by a version string
> referencing an official version in README-maintainer-mode, and not by
> "whatever version is on sourceware.cygnus.com", I'm happy.

That works until there is a bug which is a problem for the binutils
but there is not yet a new release.

It's not a theoretical point.  That's the reason we started using
versions stored on sources.redhat.com in the first place.

Ian

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

[Klee Dienes]

On Thursday, December 5, 2002, at 12:00 PM, Andrew Cagney wrote:

>> On Thursday, December 5, 2002, at 10:43 AM, Andrew Cagney wrote:
>>> I don't understand this:
>>> - $(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)
>>> isn't it independant of the switch?
>>>
>> It's a result of using the ylwrap from autoconf-1.7, which is needed 
>> since the rules for the binutils/ parsers are automatically generated 
>> by automake.
>>
> Does it work now?

I'm not sure I understand the question, but I'll elaborate on the 
situation a bit in hopes that I can answer it anyway.

Automake-1.4p5 generates Makefile.in's that use the syntax:

ylwrap PROGRAM INPUT [OUTPUT DESIRED]... -- [ARGS]...

Automake-1.7 generates Makefile.in's that use the syntax:

ylwrap INPUT [OUTPUT DESIRED]... -- PROGRAM [ARGS]...

So if we use automake-1.7 to build Makefile.in binutils/ld/gas, we need 
to use the ylwrap from automake-1.7 as well, which uses the new syntax 
and therefore requires the change to the GDB Makefile.in.   I don't 
think it's possible to have a version of the GDB Makefile.in that works 
with both versions.

>>> Same with this?
>>> -  AC_DEFINE(HAVE_LONG_DOUBLE)
>>> +  AC_DEFINE([HAVE_LONG_DOUBLE], [], [Define if the `long double' 
>>> type works])
>>> (or did the new autoconf change the interface causing a warning if 
>>> the three parameters were not present?).
>
>> Not even a warning: it blows out autoheader with an error.  The new 
>> AC_DEFINE interface deprecates the use of a template file, and 
>> instead requires all the information to be provided by the AC_DEFINE 
>> commands (it's particularly annoying since the warning about the 
>> existence of a template file is about 10 lines long, ALL CAPS, and 
>> can't be turned off with --warnings=none).
>
> Ulgh.  Same here though, does this work with autoconf 2.13++ (the 
> current offical autoconf)?

The 3-argument form works with both autoconf-2.13 and autoconf-2.50+.

Is autoconf-2.13 really the current official autoconf?  The autoconf 
release announcements don't make that at all clear:

>    - Why should I upgrade from 2.13?
>
> This version is no longer maintained.  It does not address recent
> architectures, recent compilers etc.  We know that upgrading from 2.13
> to 2.5x is not an easy task, especially because the Autoconf 2.13 was
> extremely tolerant of incorrect macro invocations, but waiting longer
> endangers the portability of your package and only delays the
> conversion to newer Autoconf versions.  Worse: some maintainers now
> spend a significant amount of time fixing bugs in 2.13 or backporting
> macros from 2.55.

Or do you mean that autoconf-2.13++ is the current official version for 
Binutils/BFD (in which case I withdraw my question)?

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

[Daniel Jacobowitz]

On Thu, Dec 05, 2002 at 03:55:37PM -0500, Klee Dienes wrote:
> 
> On Thursday, December 5, 2002, at 12:00 PM, Andrew Cagney wrote:
> 
> >>On Thursday, December 5, 2002, at 10:43 AM, Andrew Cagney wrote:
> >>>I don't understand this:
> >>>- $(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)
> >>>isn't it independant of the switch?
> >>>
> >>It's a result of using the ylwrap from autoconf-1.7, which is needed 
> >>since the rules for the binutils/ parsers are automatically generated 
> >>by automake.
> >>
> >Does it work now?
> 
> I'm not sure I understand the question, but I'll elaborate on the 
> situation a bit in hopes that I can answer it anyway.
> 
> Automake-1.4p5 generates Makefile.in's that use the syntax:
> 
> ylwrap PROGRAM INPUT [OUTPUT DESIRED]... -- [ARGS]...
> 
> Automake-1.7 generates Makefile.in's that use the syntax:
> 
> ylwrap INPUT [OUTPUT DESIRED]... -- PROGRAM [ARGS]...
> 
> So if we use automake-1.7 to build Makefile.in binutils/ld/gas, we need 
> to use the ylwrap from automake-1.7 as well, which uses the new syntax 
> and therefore requires the change to the GDB Makefile.in.   I don't 
> think it's possible to have a version of the GDB Makefile.in that works 
> with both versions.

But, to clarify even further: if we use the new ylwrap from Automake
1.7, regardless of what version of _automake_ we are using, then Klee's
patch to gdb/Makefile.in will work.

This means that all directories which use both automake and ylwrap must
be converted at the same time however.

> The 3-argument form works with both autoconf-2.13 and autoconf-2.50+.
> 
> Is autoconf-2.13 really the current official autoconf?  The autoconf 
> release announcements don't make that at all clear:
> 
> Or do you mean that autoconf-2.13++ is the current official version for 
> Binutils/BFD (in which case I withdraw my question)?

Right, that's what Andrew meant, I think.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Andrew Cagney]

> The 3-argument form works with both autoconf-2.13 and autoconf-2.50+.
> 

So the three argument form fixes can be committed now?

> I'm not sure I understand the question, but I'll elaborate on the situation a bit in hopes that I can answer it anyway.
> 
> Automake-1.4p5 generates Makefile.in's that use the syntax:
> 
> ylwrap PROGRAM INPUT [OUTPUT DESIRED]... -- [ARGS]...
> 
> Automake-1.7 generates Makefile.in's that use the syntax:
> 
> ylwrap INPUT [OUTPUT DESIRED]... -- PROGRAM [ARGS]...
> 
> So if we use automake-1.7 to build Makefile.in binutils/ld/gas, we need to use the ylwrap from automake-1.7 as well, which uses the new syntax and therefore requires the change to the GDB Makefile.in.   I don't think it's possible to have a version of the GDB Makefile.in that works with both versions. 

Right.  But can the fixes be committed now (while we potentially twiddle 
our thums waiting for the end of the northern winter :-).  I get the 
feeling that the answer is no.  Outch!

Andrew

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

[Andrew Cagney]

>> I'm not sure I understand the question, but I'll elaborate on the 
>> situation a bit in hopes that I can answer it anyway.
>> 
>> Automake-1.4p5 generates Makefile.in's that use the syntax:
>> 
>> ylwrap PROGRAM INPUT [OUTPUT DESIRED]... -- [ARGS]...
>> 
>> Automake-1.7 generates Makefile.in's that use the syntax:
>> 
>> ylwrap INPUT [OUTPUT DESIRED]... -- PROGRAM [ARGS]...
>> 
>> So if we use automake-1.7 to build Makefile.in binutils/ld/gas, we need 
>> to use the ylwrap from automake-1.7 as well, which uses the new syntax 
>> and therefore requires the change to the GDB Makefile.in.   I don't 
>> think it's possible to have a version of the GDB Makefile.in that works 
>> with both versions.
> 
> 
> But, to clarify even further: if we use the new ylwrap from Automake
> 1.7, regardless of what version of _automake_ we are using, then Klee's
> patch to gdb/Makefile.in will work.
> 
> This means that all directories which use both automake and ylwrap must
> be converted at the same time however.

[australian expletive deleted]

But GDB, which doesn't use automake, can start using the new one 
(locally) now, and get the patches committed?

Andrew

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

[Daniel Jacobowitz]

On Thu, Dec 05, 2002 at 04:13:14PM -0500, Andrew Cagney wrote:
> 
> >>I'm not sure I understand the question, but I'll elaborate on the 
> >>situation a bit in hopes that I can answer it anyway.
> >>
> >>Automake-1.4p5 generates Makefile.in's that use the syntax:
> >>
> >>ylwrap PROGRAM INPUT [OUTPUT DESIRED]... -- [ARGS]...
> >>
> >>Automake-1.7 generates Makefile.in's that use the syntax:
> >>
> >>ylwrap INPUT [OUTPUT DESIRED]... -- PROGRAM [ARGS]...
> >>
> >>So if we use automake-1.7 to build Makefile.in binutils/ld/gas, we need 
> >>to use the ylwrap from automake-1.7 as well, which uses the new syntax 
> >>and therefore requires the change to the GDB Makefile.in.   I don't 
> >>think it's possible to have a version of the GDB Makefile.in that works 
> >>with both versions.
> >
> >
> >But, to clarify even further: if we use the new ylwrap from Automake
> >1.7, regardless of what version of _automake_ we are using, then Klee's
> >patch to gdb/Makefile.in will work.
> >
> >This means that all directories which use both automake and ylwrap must
> >be converted at the same time however.
> 
> [australian expletive deleted]
> 
> But GDB, which doesn't use automake, can start using the new one 
> (locally) now, and get the patches committed?

Probably not.  It expects it to be in the toplevel directory.  Might be
able to override YLWRAP for now.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Klee Dienes]

On Thursday, December 5, 2002, at 04:08 PM, Andrew Cagney wrote:

>> The 3-argument form works with both autoconf-2.13 and autoconf-2.50+.
>
> So the three argument form fixes can be committed now?

Yes, that should be fine, though I'd have to do a test-configure/build 
of it to be 100% sure.

> Right.  But can the fixes be committed now (while we potentially 
> twiddle our thums waiting for the end of the northern winter :-).  I 
> get the feeling that the answer is no.  Outch!

We could use YLWRAP = $(srcdir)/ylwrap instead of YLWRAP = 
$(srcdir)/../ylwrap, and then include the new-style ylwrap in the GDB 
directory, if we chose to.  I suspect it'd be better just to wait until 
we are willing/able to use automake to generate the makefiles for 
binutils/ld/gas, but I have no strong opinion either way.

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

[Ben Elliston]

>>>>> "Klee" == Klee Dienes <klee@apple.com> writes:

  Klee> The idea here is that it's relatively straightforward for a
  Klee> binutils/gdb maintainer to know what to do when updating a
  Klee> configuration file (get the most recent version of the tools
  Klee> from the FSF and use them), and that we have a natural
  Klee> tendency to stay up-to-date with automake/autoconf changes,
  Klee> without having flag-day style upgrades become an issue.

The flag day has less to do with the binutils and GCC development
process and more to do with Autoconf development.  Some poor decisions
have been made there recently with respect to backward compatibility.

Ben

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

[Ben Elliston]

>>>>> "Klee" == Klee Dienes <klee@apple.com> writes:

  Klee> The idea here is that it's relatively straightforward for a
  Klee> binutils/gdb maintainer to know what to do when updating a
  Klee> configuration file (get the most recent version of the tools
  Klee> from the FSF and use them), and that we have a natural
  Klee> tendency to stay up-to-date with automake/autoconf changes,
  Klee> without having flag-day style upgrades become an issue.

The flag day has less to do with the binutils and GCC development
process and more to do with Autoconf development.  Some poor decisions
have been made there recently with respect to backward compatibility.

Ben

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

[Alan Modra]

On Thu, Dec 05, 2002 at 08:26:53AM -0500, Hans-Peter Nilsson wrote:
> On Thu, 5 Dec 2002, Klee Dienes wrote:
> > The following patch updates the following directories to use the latest
> > versions of libtool, autoconf, and automake:
> 
> Bravo!  Great!

Agreed, but it needs a little more work.  I ran Klee's script (minus
the rm and cvs update - I want to keep a few local mods!) last night
and my binutils builds went uneventfully.  There were a few make
warnings about commands being overridden, but that's a minor problem.
The big problem, as others have noted, is that "make install" doesn't
install properly on a native build.  ie. with --build=i686-linux
--host=i686-linux --target=i686-linux I get tools installed as
i686-linux-$tool rather than plain $tool.  It seems that
program_prefix is now set by configure whenever --target is
specified, which I suppose is not a bad idea.  I'm happy to have the
tools installed as i686-linux-$tool, but I want them installed as
$tool too!

One other nit: Your changelog mentions binutils/configure where
you're in fact patching the toplevel configure.  You probably need to
explain why this particular patch was necessary too.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

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

[Klee Dienes]

Sure, but is it really a common situation where we are neither able to 
revert to a previous released version of libtool, or get a release of 
the upstream tools made with the needed fix in a timely fashion?

[ Here I wake up from my optimistic reverie and proceed to answer my 
own rhetorical question: ]

The answer to this, of course, is "yes," and I agree that poor 
backwards compatibility from autoconf-2.13 to autoconf-2.50 is the real 
source of the problem here.  My point is that the current solution 
doesn't seem to be addressing the real problem --- we have essentially 
created our own forked versions of all of the autotools, with no 
visible plans to re-merge to the FSF version, and no intent to maintain 
the forked version on our own.

I'm not arguing that it will never be necessary to fork our own version 
of autotools in the case of a short-term emergency (well actually, I 
might argue that, but I'm not arguing it here).  I'm just arguing that 
a forked version of binutils with no clear upstream referent is a 
particularly bad state of affairs:

	-rw-r--r--   1 77       1002       259210 Feb 27  2000 
autoconf-000227.tar.bz2
	-rw-r--r--   1 77       1002       292827 Feb 27  2000 
automake-000227.tar.bz2
	-rw-r--r--   1 77       1002       519132 Feb 27  2000 
gettext-000227.tar.bz2
	-rw-r--r--   1 77       1002       370603 Feb 27  2000 
libtool-000227.tar.bz2


On Thursday, December 5, 2002, at 03:24 PM, Ian Lance Taylor wrote:

> Klee Dienes <klee@apple.com> writes:
>
>> As long as the versions of the tools are specified by a version string
>> referencing an official version in README-maintainer-mode, and not by
>> "whatever version is on sourceware.cygnus.com", I'm happy.
>
> That works until there is a bug which is a problem for the binutils
> but there is not yet a new release.
>
> It's not a theoretical point.  That's the reason we started using
> versions stored on sources.redhat.com in the first place.
>
> Ian

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

[Maciej W. Rozycki]

On Thu, 5 Dec 2002, Doug Evans wrote:

>  > 1) Specify the versions of autoconf/automake/libtool/gettext by 
>  > reference to official tarballs from ftp.gnu.org.
> 
> This places a requirement on the maintainers of ftp.gnu.org
> to not delete said tarballs until binutils has been updated.
> I dont' think you or they want that kind of coupling.

 Historically this is not a problem.  The maintainers of ftp.gnu.org are
not that hasty in deleting old stuff (which is the right way).  There are
old releases of autoconf back to 2.7, automake back to 1.0, gettext 0.10
and libtool 1.0.  The worst that happens is moving stuff from /gnu to
/old-gnu. 

> Better to uncouple things and have your own tarballs.
> Then you can upgrade according to your schedule, not theirs.

 Of course archiving copies separately is not a problem, either.  Then you
can write: "Get copies from ftp.gnu.org, or use versions archived here." 

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

[Maciej W. Rozycki]

On Thu, 5 Dec 2002, Andrew Cagney wrote:

> > I'd argue that we should:
> > 
> > 1) Specify the versions of autoconf/automake/libtool/gettext by reference to official tarballs from ftp.gnu.org.  In general, define the version used to be "the most recent officially released version of each tool".
> 
> Reality check.  If the offical autoconf has a bug, GDB and BINUTILS will 
> be forced to use a local version :-/

 Well, if that happens, the affected tool should be fixed eventually
(assuming the discoverer of the bug bothered submitting fixes to the
relevant maintainer).  Until then, it's much better to make a patch that
fixes the bug available, than to prepare own tarballs (or apart from). 
This way one may apply required patches to new versions of the tool.  This
simplifies local maintenance of the tool as other patches or newer
versions may be required for other software.

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

[DJ Delorie]

>  Historically this is not a problem.

Legally it is.  The first time they delete something we need, our
distribution becomes instantly illegal.

And traditionally, the GPL hasn't allowed you to put the
responsibility of providing sources on someone else.

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

[Maciej W. Rozycki]

On Fri, 6 Dec 2002, DJ Delorie wrote:

> >  Historically this is not a problem.
> 
> Legally it is.  The first time they delete something we need, our
> distribution becomes instantly illegal.
> And traditionally, the GPL hasn't allowed you to put the
> responsibility of providing sources on someone else.

 I don't understand -- AFAIK, the GNU GPL doesn't enforce everyone making
use of files generated by autoconf/automake/gettext/libtool to distribute
sources of the said tools.  As I understand, only if binutils use modified
tools, the relevant sources need to be made available.  For versions using
such tools, making the patches available is obvious (for practical
reasons, too).  Whether the original sources of the tools the patches
apply to need to be made available is unclear to me -- I can't decipher it
from the GNU GPL.  It won't hurt certainly. 

 Anyway referring to ftp.gnu.org as the primary source of original
versions of tools the way I wrote should be fine legally, too. 

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

[DJ Delorie]

IANAL, but...

>  I don't understand -- AFAIK, the GNU GPL doesn't enforce everyone
> making use of files generated by autoconf/automake/gettext/libtool
> to distribute sources of the said tools.

The preferred form for making modifications to configure is to edit
configure.in.  Autoconf is not usually a standard part of the
operating system (esp when we require specific versions).  Therefore,
it is a script used to control compilation, and must be considered
part of the source.

The only exception is that autoconf itself disclaims this connection,
and explicitly allows you to distribute configure without distributing
autoconf itself.  I didn't check the other tools.  I guess we're safe
legally.

We still have the problem of needing a specific version of the tools,
though.

> As I understand, only if binutils use modified tools, the relevant
> sources need to be made available.

There's nothing in the GPL that even mentions patches.

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

[Alexandre Oliva]

Sorry I'm a bit late in following up.  I don't follow these lists as
closely as GCC, and this should have been copied there, at least for
the parts that affects the top level, since those are shared.

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

> ltmain.sh (GNU libtool) 1.4.3

Can't do that.  The copy we use is from a newer code base than the 1.4
branch of libtool.  It's taken from a 1.5-to-be (multi-language)
branch from quite a while ago, back when the ltcf-*.sh scripts hadn't
been merged into libtool.m4.

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

> 	* .cvsignore: Add autom4te.cache.

Please don't.  autom4te.cache is an aberration.  It shouldn't be
created by default, and it shouldn't be left dangling there in the
source tree.  I'd much rather have rules that remove it as soon as
configure is rebuilt.

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

> 	* configure.in: Use AC_PROG_LEX instead of AM_PROG_LEX.
> 	* configure: Pass --build=$host_alias to sub-makes if no other
> 	value is specified.

Huh?  configure is generated from configure.in.  Besides, it's wrong
in principle.  --build is not to be the same as --host, it's the other
way round (even though autoconf 2.13 got it backwards).  Gotta find
out why we depend on build being defaulted to host and fixing that
instead.

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