Re: PATCH: Use AC_DEFUN instead of m4_defun in libtool.m4
On Sun, Jul 01, 2007 at 12:36:13PM -0500, Peter O'Gorman wrote: > On Sun, 2007-07-01 at 10:00 +0200, Paolo Bonzini wrote: > > > I don't know much about m4, autoconf nor libtool. This patch works > > > for me on both gcc and binutils. > > > > Looks good, but let's make sure it is applied to upstream libtool as well. > > > > Does gcc have lt~obsolete.m4 anywhere? Its function is to ensure that > aclocal does not use the installed libtool.m4. > I didn't see lt~obsolete.m4, ltobsolete.m4 nor ltobsolete.m4 in gcc. H.J.
PATCH: Use AC_DEFUN instead of m4_defun in libtool.m4
On Sat, Jun 30, 2007 at 11:43:09PM +0200, Andreas Schwab wrote: > "H.J. Lu" <[EMAIL PROTECTED]> writes: > > > On Sat, Jun 30, 2007 at 07:26:52PM +0200, Andreas Schwab wrote: > >> Please make sure that you have the right version of libtool installed > >> before running aclocal. > > > For reason, aclocal.m4 always has AM_PROG_LIBTOOL from the installed > > libtool.m4. Does anyone know how to avoid including installed > > libtool.m4 in aclocal.m4? > > Please see the quoted sentence. > It turns out that aclocal won't see macros defined in top level libtool.m4 unless they are defined with AC_DEFUN. _LT_CC_BASENAME, _LT_COMPILER_BOILERPLATE and _LT_LINKER_BOILERPLATE are defined with m4_defun. Since they are referenced in top level libtool.m4 and defined in installed libtool.m4, aclocal pulls in installed libtool.m4 although only thoses in top level libtool.m4 are used by autoconf. I don't know much about m4, autoconf nor libtool. This patch works for me on both gcc and binutils. H.J. --- 2007-06-30 H.J. Lu <[EMAIL PROTECTED]> * libtool.m4 (_LT_CC_BASENAME): Use AC_DEFUN instead of m4_defun. (_LT_COMPILER_BOILERPLATE): Likewise. (_LT_LINKER_BOILERPLATE): Likewise. --- binutils/libtool.m4.libtool 2007-06-01 06:42:08.0 -0700 +++ binutils/libtool.m4 2007-06-30 16:56:38.0 -0700 @@ -95,7 +95,7 @@ dnl AC_DEFUN([AM_PROG_LIBTOOL], []) # _LT_CC_BASENAME(CC) # --- # Calculate cc_basename. Skip known compiler wrappers and cross-prefix. -m4_defun([_LT_CC_BASENAME], +AC_DEFUN([_LT_CC_BASENAME], [for cc_temp in $1""; do case $cc_temp in compile | *[[\\/]]compile | ccache | *[[\\/]]ccache ) ;; @@ -851,7 +851,7 @@ compiler=$CC # # Check for compiler boilerplate output or warnings with # the simple compiler test code. -m4_defun([_LT_COMPILER_BOILERPLATE], +AC_DEFUN([_LT_COMPILER_BOILERPLATE], [m4_require([_LT_DECL_SED])dnl ac_outfile=conftest.$ac_objext echo "$lt_simple_compile_test_code" >conftest.$ac_ext @@ -865,7 +865,7 @@ $RM conftest* # -- # Check for linker boilerplate output or warnings with # the simple link test code. -m4_defun([_LT_LINKER_BOILERPLATE], +AC_DEFUN([_LT_LINKER_BOILERPLATE], [m4_require([_LT_DECL_SED])dnl ac_outfile=conftest.$ac_objext echo "$lt_simple_link_test_code" >conftest.$ac_ext
Re: PATCH: Use AC_DEFUN instead of m4_defun in libtool.m4
On Sun, Jul 01, 2007 at 10:00:03AM +0200, Paolo Bonzini wrote: > >I don't know much about m4, autoconf nor libtool. This patch works > >for me on both gcc and binutils. > > Looks good, but let's make sure it is applied to upstream libtool as well. > > Paolo > > >2007-06-30 H.J. Lu <[EMAIL PROTECTED]> > > > > * libtool.m4 (_LT_CC_BASENAME): Use AC_DEFUN instead of > > m4_defun. > > (_LT_COMPILER_BOILERPLATE): Likewise. > > (_LT_LINKER_BOILERPLATE): Likewise. > > It is fixed in th next libtool. Should I check in my work around in gcc and src? H.J.
Re: PATCH: Use AC_DEFUN instead of m4_defun in libtool.m4
On Mon, Jul 02, 2007 at 06:59:52AM +0200, Paolo Bonzini wrote: > > >It is fixed in th next libtool. Should I check in my work around > >in gcc and src? > > No, please test their bugfix and see if it works for you (just trying to > minimize the chance that it breaks next time we update). I have no time to test libtool. I will leave it ASIS. Thanks. H.J.
Re: PATCH: Use AC_DEFUN instead of m4_defun in libtool.m4
On Mon, Jul 02, 2007 at 12:37:32AM -0500, Peter O'Gorman wrote: > On Sun, 2007-07-01 at 22:09 -0700, H.J. Lu wrote: > > On Mon, Jul 02, 2007 at 06:59:52AM +0200, Paolo Bonzini wrote: > > > > > > >It is fixed in th next libtool. Should I check in my work around > > > >in gcc and src? > > > > > > No, please test their bugfix and see if it works for you (just trying to > > > minimize the chance that it breaks next time we update). > > > > I have no time to test libtool. I will leave it ASIS. > > I think you misunderstand, it is fixed in the version of libtool that > gcc is using, but gcc is missing a file, lt~obsolete.m4. I don't get it. Shouldn't libtool in gcc require lt~obsolete.m4 so that it won't be missing in the first place? To me, a missing lt~obsolete.m4 is a bug in libtool. H.J.
Re: PATCH: Use AC_DEFUN instead of m4_defun in libtool.m4
On Mon, Jul 02, 2007 at 10:32:18AM +0200, Paolo Bonzini wrote: > H.J. Lu wrote: > >On Mon, Jul 02, 2007 at 06:59:52AM +0200, Paolo Bonzini wrote: > >>>It is fixed in th next libtool. Should I check in my work around > >>>in gcc and src? > >>No, please test their bugfix and see if it works for you (just trying to > >>minimize the chance that it breaks next time we update). > > > >I have no time to test libtool. I will leave it ASIS. > > You don't need to test ANYTHING but gcc. Your system shows the bug, > mine doesn't, so *you* can tell best if the patch fixes it. > > You should apply Ralf's patch (the *.m4 hunks) and regenerate all > affected aclocal.m4 files in gcc and src. > Import lt~obsolete.m4 from 20070318 libtool works for me. BTW, this line --- # These exist entirely to fool aclocal when bootstrapping libtool. --- is very much misleading and I believe it should be modified. H.J. --- 2007-07-02 H.J. Lu <[EMAIL PROTECTED]> * lt~obsolete.m4: New. Import from 20070318 libtool. --- lt~obsolete.m4.libtool 2007-07-02 06:40:19.0 -0700 +++ lt~obsolete.m4 2007-07-02 06:35:21.0 -0700 @@ -0,0 +1,89 @@ +# lt~obsolete.m4 -- aclocal satisfying obsolete definitions.-*-Autoconf-*- +# +# Copyright (C) 2004, 2005 Free Software Foundation, Inc. +# Written by Scott James Remnant. +# +# This file is free software; the Free Software Foundation gives +# unlimited permission to copy and/or distribute it, with or without +# modifications, as long as this notice is preserved. + +# serial 2 + +# These exist entirely to fool aclocal when bootstrapping libtool. +# +# In the past libtool.m4 has provided macros via AC_DEFUN (or AU_DEFUN) +# which have later been changed to m4_define as they aren't part of the +# exported API, or moved to Autoconf or Automake where they belong. +# +# The trouble is, aclocal is a bit thick. It'll see the old AC_DEFUN +# in /usr/share/aclocal/libtool.m4 and remember it, then when it sees us +# using a macro with the same name in our local m4/libtool.m4 it'll +# pull the old libtool.m4 in (it doesn't see our shiny new m4_define +# and doesn't know about Autoconf macros at all.) +# +# So we provide this file, which has a silly filename so it's always +# included after everything else. This provides aclocal with the +# AC_DEFUNs it wants, but when m4 processes it, it doesn't do anything +# because those macros already exist, or will be overwritten later. +# We use AC_DEFUN over AU_DEFUN for compatibility with aclocal-1.6. +# +# Anytime we withdraw an AC_DEFUN or AU_DEFUN, remember to add it here. +# Yes, that means every name once taken will need to remain here until +# we give up compatibility with versions before 1.7, at which point +# we need to keep only those names which we still refer to. + +m4_ifndef([AC_LIBTOOL_LINKER_OPTION], [AC_DEFUN([AC_LIBTOOL_LINKER_OPTION])]) +m4_ifndef([AC_PROG_EGREP], [AC_DEFUN([AC_PROG_EGREP])]) +m4_ifndef([_LT_AC_PROG_ECHO_BACKSLASH], [AC_DEFUN([_LT_AC_PROG_ECHO_BACKSLASH])]) +m4_ifndef([_LT_AC_SHELL_INIT], [AC_DEFUN([_LT_AC_SHELL_INIT])]) +m4_ifndef([_LT_AC_SYS_LIBPATH_AIX],[AC_DEFUN([_LT_AC_SYS_LIBPATH_AIX])]) +m4_ifndef([_LT_PROG_LTMAIN], [AC_DEFUN([_LT_PROG_LTMAIN])]) +m4_ifndef([_LT_AC_TAGVAR], [AC_DEFUN([_LT_AC_TAGVAR])]) +m4_ifndef([AC_LTDL_ENABLE_INSTALL],[AC_DEFUN([AC_LTDL_ENABLE_INSTALL])]) +m4_ifndef([AC_LTDL_PREOPEN], [AC_DEFUN([AC_LTDL_PREOPEN])]) +m4_ifndef([_LT_AC_SYS_COMPILER], [AC_DEFUN([_LT_AC_SYS_COMPILER])]) +m4_ifndef([_LT_AC_LOCK], [AC_DEFUN([_LT_AC_LOCK])]) +m4_ifndef([AC_LIBTOOL_SYS_OLD_ARCHIVE], [AC_DEFUN([AC_LIBTOOL_SYS_OLD_ARCHIVE])]) +m4_ifndef([_LT_AC_TRY_DLOPEN_SELF],[AC_DEFUN([_LT_AC_TRY_DLOPEN_SELF])]) +m4_ifndef([AC_LIBTOOL_PROG_CC_C_O],[AC_DEFUN([AC_LIBTOOL_PROG_CC_C_O])]) +m4_ifndef([AC_LIBTOOL_SYS_HARD_LINK_LOCKS], [AC_DEFUN([AC_LIBTOOL_SYS_HARD_LINK_LOCKS])]) +m4_ifndef([AC_LIBTOOL_OBJDIR], [AC_DEFUN([AC_LIBTOOL_OBJDIR])]) +m4_ifndef([AC_LTDL_OBJDIR],[AC_DEFUN([AC_LTDL_OBJDIR])]) +m4_ifndef([AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH], [AC_DEFUN([AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH])]) +m4_ifndef([AC_LIBTOOL_SYS_LIB_STRIP], [AC_DEFUN([AC_LIBTOOL_SYS_LIB_STRIP])]) +m4_ifndef([AC_PATH_MAGIC], [AC_DEFUN([AC_PATH_MAGIC])]) +m4_ifndef([AC_PROG_LD_GNU],[AC_DEFUN([AC_PROG_LD_GNU])]) +m4_ifndef([AC_PROG_LD_RELOAD_FLAG],[AC_DEFUN([AC_PROG_LD_RELOAD_FLAG])]) +m4_ifndef([AC_DEPLIBS_CHECK_METHOD], [AC_DEFUN([AC_DEPLIBS_CHECK_METHOD])]) +m4_ifndef([AC_LIBTOOL_PROG_COMPILER_NO_RTTI], [AC_DEFUN([AC_LIBTOOL_PROG_COMPILER_NO_RTTI])]) +m4_ifndef([AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE], [AC_DEFUN([AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE])]) +m4_ifndef([AC_LIBTOOL_PROG_COMPILER_PIC], [AC_DEFUN([AC_LIBTOOL_
Re: PATCH: Use AC_DEFUN instead of m4_defun in libtool.m4
On Mon, Jul 02, 2007 at 06:46:22AM -0700, H.J. Lu wrote: > On Mon, Jul 02, 2007 at 10:32:18AM +0200, Paolo Bonzini wrote: > > H.J. Lu wrote: > > >On Mon, Jul 02, 2007 at 06:59:52AM +0200, Paolo Bonzini wrote: > > >>>It is fixed in th next libtool. Should I check in my work around > > >>>in gcc and src? > > >>No, please test their bugfix and see if it works for you (just trying to > > >>minimize the chance that it breaks next time we update). > > > > > >I have no time to test libtool. I will leave it ASIS. > > > > You don't need to test ANYTHING but gcc. Your system shows the bug, > > mine doesn't, so *you* can tell best if the patch fixes it. > > > > You should apply Ralf's patch (the *.m4 hunks) and regenerate all > > affected aclocal.m4 files in gcc and src. > > > > Import lt~obsolete.m4 from 20070318 libtool works for me. > > BTW, this line > > --- > # These exist entirely to fool aclocal when bootstrapping libtool. > --- > > is very much misleading and I believe it should be modified. > > > H.J. > --- > 2007-07-02 H.J. Lu <[EMAIL PROTECTED]> > > * lt~obsolete.m4: New. Import from 20070318 libtool. > Can I check in this patch? Thanks. H.J.
PATCH: Add x32 support to _LT_ENABLE_LOCK
Hi,
Here is a patch to update _LT_ENABLE_LOCK to support x32:
https://sites.google.com/site/x32abi/home
which is the 32bit ABI for x86-64. Binutils 2.22 supports "-m elf32_x86_64"
for x32.
H.J.
---
2011-12-12 H.J. Lu
* m4/libtool.m4 (_LT_ENABLE_LOCK): Support x32.
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 9c2574f..3639851 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1321,7 +1321,14 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
LD="${LD-ld} -m elf_i386_fbsd"
;;
x86_64-*linux*)
- LD="${LD-ld} -m elf_i386"
+ case `/usr/bin/file conftest.o` in
+ *x86-64*)
+ LD="${LD-ld} -m elf32_x86_64"
+ ;;
+ *)
+ LD="${LD-ld} -m elf_i386"
+ ;;
+ esac
;;
ppc64-*linux*|powerpc64-*linux*)
LD="${LD-ld} -m elf32ppclinux"
