* [RFA/PATCH] Darwin fixes for ltconfig, ltcf-c.sh
@ 2002-11-13 8:55 Klee Dienes
2002-11-13 9:57 ` Andrew Cagney
0 siblings, 1 reply; 44+ messages in thread
From: Klee Dienes @ 2002-11-13 8:55 UTC (permalink / raw)
To: binutils; +Cc: gdb-patches
[-- 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
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: [RFA/PATCH] Darwin fixes for ltconfig, ltcf-c.sh 2002-11-13 8:55 [RFA/PATCH] Darwin fixes for ltconfig, ltcf-c.sh Klee Dienes @ 2002-11-13 9:57 ` Andrew Cagney 2002-11-13 10:32 ` Klee Dienes 0 siblings, 1 reply; 44+ messages in thread From: Andrew Cagney @ 2002-11-13 9:57 UTC (permalink / raw) To: Klee Dienes; +Cc: binutils, gdb-patches 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFA/PATCH] Darwin fixes for ltconfig, ltcf-c.sh 2002-11-13 9:57 ` Andrew Cagney @ 2002-11-13 10:32 ` Klee Dienes 2002-12-04 22:04 ` [RFC] Update to current automake/autoconf/libtool versions Klee Dienes 0 siblings, 1 reply; 44+ messages in thread From: Klee Dienes @ 2002-11-13 10:32 UTC (permalink / raw) To: Andrew Cagney; +Cc: binutils, gdb-patches 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* [RFC] Update to current automake/autoconf/libtool versions. 2002-11-13 10:32 ` Klee Dienes @ 2002-12-04 22:04 ` Klee Dienes 2002-12-05 5:26 ` Hans-Peter Nilsson ` (4 more replies) 0 siblings, 5 replies; 44+ messages in thread From: Klee Dienes @ 2002-12-04 22:04 UTC (permalink / raw) To: Andrew Cagney; +Cc: binutils, gdb-patches [-- 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-04 22:04 ` [RFC] Update to current automake/autoconf/libtool versions Klee Dienes @ 2002-12-05 5:26 ` Hans-Peter Nilsson 2002-12-05 14:07 ` Alan Modra 2002-12-05 7:43 ` Andrew Cagney ` (3 subsequent siblings) 4 siblings, 1 reply; 44+ messages in thread From: Hans-Peter Nilsson @ 2002-12-05 5:26 UTC (permalink / raw) To: Klee Dienes; +Cc: binutils, gdb-patches 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 5:26 ` Hans-Peter Nilsson @ 2002-12-05 14:07 ` Alan Modra 0 siblings, 0 replies; 44+ messages in thread From: Alan Modra @ 2002-12-05 14:07 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: Klee Dienes, binutils, gdb-patches 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-04 22:04 ` [RFC] Update to current automake/autoconf/libtool versions Klee Dienes 2002-12-05 5:26 ` Hans-Peter Nilsson @ 2002-12-05 7:43 ` Andrew Cagney 2002-12-05 8:22 ` Klee Dienes ` (2 more replies) 2002-12-05 7:44 ` Maciej W. Rozycki ` (2 subsequent siblings) 4 siblings, 3 replies; 44+ messages in thread From: Andrew Cagney @ 2002-12-05 7:43 UTC (permalink / raw) To: Klee Dienes; +Cc: binutils, gdb-patches 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 7:43 ` Andrew Cagney @ 2002-12-05 8:22 ` Klee Dienes 2002-12-05 9:01 ` Andrew Cagney 2002-12-05 8:28 ` DJ Delorie 2002-12-05 9:31 ` H. J. Lu 2 siblings, 1 reply; 44+ messages in thread From: Klee Dienes @ 2002-12-05 8:22 UTC (permalink / raw) To: Andrew Cagney; +Cc: binutils, gdb-patches 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 8:22 ` Klee Dienes @ 2002-12-05 9:01 ` Andrew Cagney 2002-12-05 12:55 ` Klee Dienes 0 siblings, 1 reply; 44+ messages in thread From: Andrew Cagney @ 2002-12-05 9:01 UTC (permalink / raw) To: Klee Dienes; +Cc: binutils, gdb-patches > 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 9:01 ` Andrew Cagney @ 2002-12-05 12:55 ` Klee Dienes 2002-12-05 13:03 ` Daniel Jacobowitz 2002-12-05 13:08 ` Andrew Cagney 0 siblings, 2 replies; 44+ messages in thread From: Klee Dienes @ 2002-12-05 12:55 UTC (permalink / raw) To: Andrew Cagney; +Cc: binutils, gdb-patches 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)? ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 12:55 ` Klee Dienes @ 2002-12-05 13:03 ` Daniel Jacobowitz 2002-12-05 13:13 ` Andrew Cagney 2002-12-05 13:08 ` Andrew Cagney 1 sibling, 1 reply; 44+ messages in thread From: Daniel Jacobowitz @ 2002-12-05 13:03 UTC (permalink / raw) To: Klee Dienes; +Cc: Andrew Cagney, binutils, gdb-patches 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 13:03 ` Daniel Jacobowitz @ 2002-12-05 13:13 ` Andrew Cagney 2002-12-05 13:16 ` Daniel Jacobowitz 0 siblings, 1 reply; 44+ messages in thread From: Andrew Cagney @ 2002-12-05 13:13 UTC (permalink / raw) To: Daniel Jacobowitz, Klee Dienes; +Cc: binutils, gdb-patches >> 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 13:13 ` Andrew Cagney @ 2002-12-05 13:16 ` Daniel Jacobowitz 0 siblings, 0 replies; 44+ messages in thread From: Daniel Jacobowitz @ 2002-12-05 13:16 UTC (permalink / raw) To: Andrew Cagney; +Cc: Klee Dienes, binutils, gdb-patches 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 12:55 ` Klee Dienes 2002-12-05 13:03 ` Daniel Jacobowitz @ 2002-12-05 13:08 ` Andrew Cagney 2002-12-05 13:18 ` Klee Dienes 1 sibling, 1 reply; 44+ messages in thread From: Andrew Cagney @ 2002-12-05 13:08 UTC (permalink / raw) To: Klee Dienes; +Cc: binutils, gdb-patches > 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 13:08 ` Andrew Cagney @ 2002-12-05 13:18 ` Klee Dienes 0 siblings, 0 replies; 44+ messages in thread From: Klee Dienes @ 2002-12-05 13:18 UTC (permalink / raw) To: Andrew Cagney; +Cc: binutils, gdb-patches 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 7:43 ` Andrew Cagney 2002-12-05 8:22 ` Klee Dienes @ 2002-12-05 8:28 ` DJ Delorie 2002-12-05 9:37 ` Klee Dienes 2002-12-05 9:31 ` H. J. Lu 2 siblings, 1 reply; 44+ messages in thread From: DJ Delorie @ 2002-12-05 8:28 UTC (permalink / raw) To: binutils; +Cc: gdb-patches > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 8:28 ` DJ Delorie @ 2002-12-05 9:37 ` Klee Dienes 2002-12-05 9:42 ` DJ Delorie 0 siblings, 1 reply; 44+ messages in thread From: Klee Dienes @ 2002-12-05 9:37 UTC (permalink / raw) To: DJ Delorie; +Cc: binutils, gdb-patches 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. > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 9:37 ` Klee Dienes @ 2002-12-05 9:42 ` DJ Delorie 2002-12-05 10:28 ` Klee Dienes 0 siblings, 1 reply; 44+ messages in thread From: DJ Delorie @ 2002-12-05 9:42 UTC (permalink / raw) To: klee; +Cc: binutils, gdb-patches > 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? ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 9:42 ` DJ Delorie @ 2002-12-05 10:28 ` Klee Dienes 0 siblings, 0 replies; 44+ messages in thread From: Klee Dienes @ 2002-12-05 10:28 UTC (permalink / raw) To: DJ Delorie; +Cc: binutils, gdb-patches 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? ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 7:43 ` Andrew Cagney 2002-12-05 8:22 ` Klee Dienes 2002-12-05 8:28 ` DJ Delorie @ 2002-12-05 9:31 ` H. J. Lu 2 siblings, 0 replies; 44+ messages in thread From: H. J. Lu @ 2002-12-05 9:31 UTC (permalink / raw) To: Andrew Cagney; +Cc: Klee Dienes, binutils, gdb-patches 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-04 22:04 ` [RFC] Update to current automake/autoconf/libtool versions Klee Dienes 2002-12-05 5:26 ` Hans-Peter Nilsson 2002-12-05 7:43 ` Andrew Cagney @ 2002-12-05 7:44 ` Maciej W. Rozycki 2002-12-05 9:01 ` Klee Dienes 2002-12-05 8:09 ` Daniel Jacobowitz 2002-12-30 16:10 ` Alexandre Oliva 4 siblings, 1 reply; 44+ messages in thread From: Maciej W. Rozycki @ 2002-12-05 7:44 UTC (permalink / raw) To: Klee Dienes; +Cc: Andrew Cagney, binutils, gdb-patches 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 + ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 7:44 ` Maciej W. Rozycki @ 2002-12-05 9:01 ` Klee Dienes 0 siblings, 0 replies; 44+ messages in thread From: Klee Dienes @ 2002-12-05 9:01 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: binutils, gdb-patches 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-04 22:04 ` [RFC] Update to current automake/autoconf/libtool versions Klee Dienes ` (2 preceding siblings ...) 2002-12-05 7:44 ` Maciej W. Rozycki @ 2002-12-05 8:09 ` Daniel Jacobowitz 2002-12-05 8:29 ` DJ Delorie 2002-12-30 16:10 ` Alexandre Oliva 4 siblings, 1 reply; 44+ messages in thread From: Daniel Jacobowitz @ 2002-12-05 8:09 UTC (permalink / raw) To: Klee Dienes; +Cc: Andrew Cagney, binutils, gdb-patches 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 8:09 ` Daniel Jacobowitz @ 2002-12-05 8:29 ` DJ Delorie 2002-12-05 8:35 ` Daniel Jacobowitz 0 siblings, 1 reply; 44+ messages in thread From: DJ Delorie @ 2002-12-05 8:29 UTC (permalink / raw) To: drow; +Cc: klee, ac131313, binutils, gdb-patches > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 8:29 ` DJ Delorie @ 2002-12-05 8:35 ` Daniel Jacobowitz 2002-12-05 8:37 ` DJ Delorie 2002-12-05 8:40 ` Maciej W. Rozycki 0 siblings, 2 replies; 44+ messages in thread From: Daniel Jacobowitz @ 2002-12-05 8:35 UTC (permalink / raw) To: DJ Delorie; +Cc: klee, ac131313, binutils, gdb-patches 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 8:35 ` Daniel Jacobowitz @ 2002-12-05 8:37 ` DJ Delorie 2002-12-05 8:40 ` Maciej W. Rozycki 1 sibling, 0 replies; 44+ messages in thread From: DJ Delorie @ 2002-12-05 8:37 UTC (permalink / raw) To: drow; +Cc: klee, ac131313, binutils, gdb-patches > > > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 8:35 ` Daniel Jacobowitz 2002-12-05 8:37 ` DJ Delorie @ 2002-12-05 8:40 ` Maciej W. Rozycki 2002-12-05 8:44 ` Daniel Jacobowitz 1 sibling, 1 reply; 44+ messages in thread From: Maciej W. Rozycki @ 2002-12-05 8:40 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: DJ Delorie, klee, ac131313, binutils, gdb-patches 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 + ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 8:40 ` Maciej W. Rozycki @ 2002-12-05 8:44 ` Daniel Jacobowitz 2002-12-05 9:19 ` Elena Zannoni 2002-12-05 9:54 ` Klee Dienes 0 siblings, 2 replies; 44+ messages in thread From: Daniel Jacobowitz @ 2002-12-05 8:44 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: DJ Delorie, klee, ac131313, binutils, gdb-patches 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 8:44 ` Daniel Jacobowitz @ 2002-12-05 9:19 ` Elena Zannoni 2002-12-05 9:54 ` Klee Dienes 1 sibling, 0 replies; 44+ messages in thread From: Elena Zannoni @ 2002-12-05 9:19 UTC (permalink / raw) To: Daniel Jacobowitz Cc: Maciej W. Rozycki, DJ Delorie, klee, ac131313, binutils, gdb-patches 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 8:44 ` Daniel Jacobowitz 2002-12-05 9:19 ` Elena Zannoni @ 2002-12-05 9:54 ` Klee Dienes 2002-12-05 10:10 ` Maciej W. Rozycki ` (3 more replies) 1 sibling, 4 replies; 44+ messages in thread From: Klee Dienes @ 2002-12-05 9:54 UTC (permalink / raw) To: Daniel Jacobowitz Cc: Maciej W. Rozycki, DJ Delorie, ac131313, binutils, gdb-patches 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 9:54 ` Klee Dienes @ 2002-12-05 10:10 ` Maciej W. Rozycki 2002-12-05 10:59 ` Doug Evans ` (2 subsequent siblings) 3 siblings, 0 replies; 44+ messages in thread From: Maciej W. Rozycki @ 2002-12-05 10:10 UTC (permalink / raw) To: Klee Dienes Cc: Daniel Jacobowitz, DJ Delorie, ac131313, binutils, gdb-patches 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 + ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 9:54 ` Klee Dienes 2002-12-05 10:10 ` Maciej W. Rozycki @ 2002-12-05 10:59 ` Doug Evans 2002-12-05 12:11 ` Klee Dienes 2002-12-06 5:34 ` Maciej W. Rozycki 2002-12-05 10:59 ` Andrew Cagney 2002-12-05 13:59 ` Ben Elliston 3 siblings, 2 replies; 44+ messages in thread From: Doug Evans @ 2002-12-05 10:59 UTC (permalink / raw) To: Klee Dienes Cc: Daniel Jacobowitz, Maciej W. Rozycki, DJ Delorie, ac131313, binutils, gdb-patches 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 10:59 ` Doug Evans @ 2002-12-05 12:11 ` Klee Dienes 2002-12-05 12:23 ` Ian Lance Taylor 2002-12-06 5:34 ` Maciej W. Rozycki 1 sibling, 1 reply; 44+ messages in thread From: Klee Dienes @ 2002-12-05 12:11 UTC (permalink / raw) To: Doug Evans Cc: Daniel Jacobowitz, Maciej W. Rozycki, DJ Delorie, ac131313, binutils, gdb-patches 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 12:11 ` Klee Dienes @ 2002-12-05 12:23 ` Ian Lance Taylor 2002-12-05 14:29 ` Klee Dienes 0 siblings, 1 reply; 44+ messages in thread From: Ian Lance Taylor @ 2002-12-05 12:23 UTC (permalink / raw) To: Klee Dienes Cc: Doug Evans, Daniel Jacobowitz, Maciej W. Rozycki, DJ Delorie, ac131313, binutils, gdb-patches 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 12:23 ` Ian Lance Taylor @ 2002-12-05 14:29 ` Klee Dienes 0 siblings, 0 replies; 44+ messages in thread From: Klee Dienes @ 2002-12-05 14:29 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: binutils, gdb-patches 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 10:59 ` Doug Evans 2002-12-05 12:11 ` Klee Dienes @ 2002-12-06 5:34 ` Maciej W. Rozycki 2002-12-06 7:25 ` DJ Delorie 1 sibling, 1 reply; 44+ messages in thread From: Maciej W. Rozycki @ 2002-12-06 5:34 UTC (permalink / raw) To: Doug Evans Cc: Klee Dienes, Daniel Jacobowitz, DJ Delorie, ac131313, binutils, gdb-patches 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 + ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-06 5:34 ` Maciej W. Rozycki @ 2002-12-06 7:25 ` DJ Delorie 2002-12-06 8:06 ` Maciej W. Rozycki 0 siblings, 1 reply; 44+ messages in thread From: DJ Delorie @ 2002-12-06 7:25 UTC (permalink / raw) To: macro; +Cc: binutils, gdb-patches > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-06 7:25 ` DJ Delorie @ 2002-12-06 8:06 ` Maciej W. Rozycki 2002-12-06 8:47 ` DJ Delorie 0 siblings, 1 reply; 44+ messages in thread From: Maciej W. Rozycki @ 2002-12-06 8:06 UTC (permalink / raw) To: DJ Delorie; +Cc: binutils, gdb-patches 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 + ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-06 8:06 ` Maciej W. Rozycki @ 2002-12-06 8:47 ` DJ Delorie 0 siblings, 0 replies; 44+ messages in thread From: DJ Delorie @ 2002-12-06 8:47 UTC (permalink / raw) To: macro; +Cc: binutils, gdb-patches 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 9:54 ` Klee Dienes 2002-12-05 10:10 ` Maciej W. Rozycki 2002-12-05 10:59 ` Doug Evans @ 2002-12-05 10:59 ` Andrew Cagney 2002-12-06 5:52 ` Maciej W. Rozycki 2002-12-05 13:59 ` Ben Elliston 3 siblings, 1 reply; 44+ messages in thread From: Andrew Cagney @ 2002-12-05 10:59 UTC (permalink / raw) To: Klee Dienes Cc: Daniel Jacobowitz, Maciej W. Rozycki, DJ Delorie, binutils, gdb-patches > 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 10:59 ` Andrew Cagney @ 2002-12-06 5:52 ` Maciej W. Rozycki 0 siblings, 0 replies; 44+ messages in thread From: Maciej W. Rozycki @ 2002-12-06 5:52 UTC (permalink / raw) To: Andrew Cagney Cc: Klee Dienes, Daniel Jacobowitz, DJ Delorie, binutils, gdb-patches 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 + ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 9:54 ` Klee Dienes ` (2 preceding siblings ...) 2002-12-05 10:59 ` Andrew Cagney @ 2002-12-05 13:59 ` Ben Elliston 2002-12-05 13:41 ` Ben Elliston 3 siblings, 1 reply; 44+ messages in thread From: Ben Elliston @ 2002-12-05 13:59 UTC (permalink / raw) To: gdb-patches; +Cc: binutils >>>>> "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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-05 13:59 ` Ben Elliston @ 2002-12-05 13:41 ` Ben Elliston 0 siblings, 0 replies; 44+ messages in thread From: Ben Elliston @ 2002-12-05 13:41 UTC (permalink / raw) To: gdb-patches; +Cc: binutils >>>>> "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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [RFC] Update to current automake/autoconf/libtool versions. 2002-12-04 22:04 ` [RFC] Update to current automake/autoconf/libtool versions Klee Dienes ` (3 preceding siblings ...) 2002-12-05 8:09 ` Daniel Jacobowitz @ 2002-12-30 16:10 ` Alexandre Oliva 4 siblings, 0 replies; 44+ messages in thread From: Alexandre Oliva @ 2002-12-30 16:10 UTC (permalink / raw) To: Klee Dienes; +Cc: Andrew Cagney, binutils, gdb-patches 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2002-12-30 19:41 UTC | newest] Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-11-13 8:55 [RFA/PATCH] Darwin fixes for ltconfig, ltcf-c.sh Klee Dienes 2002-11-13 9:57 ` Andrew Cagney 2002-11-13 10:32 ` Klee Dienes 2002-12-04 22:04 ` [RFC] Update to current automake/autoconf/libtool versions Klee Dienes 2002-12-05 5:26 ` Hans-Peter Nilsson 2002-12-05 14:07 ` Alan Modra 2002-12-05 7:43 ` Andrew Cagney 2002-12-05 8:22 ` Klee Dienes 2002-12-05 9:01 ` Andrew Cagney 2002-12-05 12:55 ` Klee Dienes 2002-12-05 13:03 ` Daniel Jacobowitz 2002-12-05 13:13 ` Andrew Cagney 2002-12-05 13:16 ` Daniel Jacobowitz 2002-12-05 13:08 ` Andrew Cagney 2002-12-05 13:18 ` Klee Dienes 2002-12-05 8:28 ` DJ Delorie 2002-12-05 9:37 ` Klee Dienes 2002-12-05 9:42 ` DJ Delorie 2002-12-05 10:28 ` Klee Dienes 2002-12-05 9:31 ` H. J. Lu 2002-12-05 7:44 ` Maciej W. Rozycki 2002-12-05 9:01 ` Klee Dienes 2002-12-05 8:09 ` Daniel Jacobowitz 2002-12-05 8:29 ` DJ Delorie 2002-12-05 8:35 ` Daniel Jacobowitz 2002-12-05 8:37 ` DJ Delorie 2002-12-05 8:40 ` Maciej W. Rozycki 2002-12-05 8:44 ` Daniel Jacobowitz 2002-12-05 9:19 ` Elena Zannoni 2002-12-05 9:54 ` Klee Dienes 2002-12-05 10:10 ` Maciej W. Rozycki 2002-12-05 10:59 ` Doug Evans 2002-12-05 12:11 ` Klee Dienes 2002-12-05 12:23 ` Ian Lance Taylor 2002-12-05 14:29 ` Klee Dienes 2002-12-06 5:34 ` Maciej W. Rozycki 2002-12-06 7:25 ` DJ Delorie 2002-12-06 8:06 ` Maciej W. Rozycki 2002-12-06 8:47 ` DJ Delorie 2002-12-05 10:59 ` Andrew Cagney 2002-12-06 5:52 ` Maciej W. Rozycki 2002-12-05 13:59 ` Ben Elliston 2002-12-05 13:41 ` Ben Elliston 2002-12-30 16:10 ` Alexandre Oliva
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox