[libmudflap] Why was the toplevel libtool.m4 copied into acinclude.m4?

[libmudflap] Why was the toplevel libtool.m4 copied into acinclude.m4?

[Kelley Cook]

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

Does someone recall the reason why back in January 2003 the toplevel 
libtool copied into acinclude.m4?  This seems to be done for a purpose, 
but I haven't been able to determine what the reason was. See 
http://gcc.gnu.org/ml/gcc-patches/2003-01/msg00264.html

This of course was done back before we converted GCC to the recent 
autotools, so it may have been a work around of some old bug.  The 
2003-01-06 regenerated aclocal.m4 as well as the resultant configure 
were very different from the previous version, which leads me to 
question whether the old autotools were previously actually picking up 
the toplevel libtool.m4.

If you delete the 928 line acinclude.m4 and put an ACLOCAL_AMFLAGS=I .. 
in Makefile.am followed by autoreconf with ac2.59/am1.9.3 it leads to 
the following differences in "configure" compared to the current 
directory simply autoreconf'd with the same versions.

The differences look innocuous, but I thought I would first ask those 
who did this.

The new version still bootstraps on i686-pc-cygwin with 
--enable-libmudflap (though this is probably a poor test as almost every 
libmudflap test fails under cygwin).

KC

[-- Attachment #2: libffi_configure.diff --]
[-- Type: text/plain, Size: 3683 bytes --]

--- ../libmudflap_193/configure	2004-11-16 09:49:41.000000000 -0500
+++ configure	2004-11-17 12:46:33.177528400 -0500
@@ -5267,7 +5267,10 @@ fi
 
 echo "$as_me:$LINENO: checking how to recognise dependant libraries" >&5
 echo $ECHO_N "checking how to recognise dependant libraries... $ECHO_C" >&6
-lt_cv_file_magic_cmd='$MAGIC_CMD'
+if test "${lt_cv_deplibs_check_method+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  lt_cv_file_magic_cmd='$MAGIC_CMD'
 lt_cv_file_magic_test_file=
 lt_cv_deplibs_check_method='unknown'
 # Need to set the preceding variable on all platforms that support
@@ -5302,6 +5305,7 @@ cygwin* | mingw* |pw32*)
   ;;
 
 darwin* | rhapsody*)
+  # this will be overwritten by pass_all, but leave it in just in case
   lt_cv_deplibs_check_method='file_magic Mach-O dynamically linked shared library'
   lt_cv_file_magic_cmd='/usr/bin/file -L'
   case "$host_os" in
@@ -5312,9 +5316,10 @@ darwin* | rhapsody*)
     lt_cv_file_magic_test_file='/usr/lib/libSystem.dylib'
     ;;
   esac
+  lt_cv_deplibs_check_method=pass_all
   ;;
 
-freebsd* )
+freebsd* | kfreebsd*-gnu)
   if echo __ELF__ | $CC -E - | grep __ELF__ > /dev/null; then
     case $host_cpu in
     i*86 )
@@ -5373,11 +5378,8 @@ irix5* | irix6*)
 # This must be Linux ELF.
 linux-gnu*)
   case $host_cpu in
-  alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* | x86_64* | sh*)
+  alpha* | mips* | hppa* | i*86 | powerpc* | sparc* | ia64* | sh* )
     lt_cv_deplibs_check_method=pass_all ;;
-    # NB 2003-06-03: According to Alexandre Oliva, x86_64 should not be
-    # in this list.  However, it works around a libtool problem that
-    # wrongly excludes -ldl/-lpthread from the libmudflap(th) dependencies.
   *)
     # glibc up to 2.1.1 does not perform some relocations on ARM
     lt_cv_deplibs_check_method='file_magic ELF [0-9][0-9]*-bit [LM]SB (shared object|dynamic lib )' ;;
@@ -5385,7 +5387,7 @@ linux-gnu*)
   lt_cv_file_magic_test_file=`echo /lib/libc.so* /lib/libc-*.so`
   ;;
 
-netbsd*)
+netbsd* | knetbsd*-gnu)
   if echo __ELF__ | $CC -E - | grep __ELF__ > /dev/null; then
     lt_cv_deplibs_check_method='match_pattern /lib[^/\.]+\.so\.[0-9]+\.[0-9]+$'
   else
@@ -5431,14 +5433,12 @@ sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
   esac
   ;;
 esac
+
+fi
+echo "$as_me:$LINENO: result: $lt_cv_deplibs_check_method" >&5
+echo "${ECHO_T}$lt_cv_deplibs_check_method" >&6
 file_magic_cmd=$lt_cv_file_magic_cmd
 deplibs_check_method=$lt_cv_deplibs_check_method
-# NB: See above NB ... this is to make sure that the overriden
-#     local libtool variant doesn't pollute the upstream cache
-unset lt_cv_file_magic_cmd
-unset lt_cv_deplibs_check_method
-echo "$as_me:$LINENO: result: $deplibs_check_method" >&5
-echo "${ECHO_T}$deplibs_check_method" >&6
 
 
 
@@ -5783,6 +5783,19 @@ case $host in
   ac_status=$?
   echo "$as_me:$LINENO: \$? = $ac_status" >&5
   (exit $ac_status); }; then
+   if test "$lt_cv_prog_gnu_ld" = yes; then
+    case `/usr/bin/file conftest.$ac_objext` in
+    *32-bit*)
+      LD="${LD-ld} -melf32bsmip"
+      ;;
+    *N32*)
+      LD="${LD-ld} -melf32bmipn32"
+      ;;
+    *64-bit*)
+      LD="${LD-ld} -melf64bmip"
+      ;;
+    esac
+   else
     case `/usr/bin/file conftest.$ac_objext` in
     *32-bit*)
       LD="${LD-ld} -32"
@@ -5794,6 +5807,7 @@ case $host in
       LD="${LD-ld} -64"
       ;;
     esac
+   fi
   fi
   rm -rf conftest*
   ;;
@@ -5832,7 +5846,7 @@ x86_64-*linux*|ppc*-*linux*|powerpc*-*li
         x86_64-*linux*)
           LD="${LD-ld} -m elf_i386"
           ;;
-        ppc64-*linux*)
+        ppc64-*linux*|powerpc64-*linux*)
           LD="${LD-ld} -m elf32ppclinux"
           ;;
         s390x-*linux*)

Re: [libmudflap] Why was the toplevel libtool.m4 copied into acinclude.m4?

[Frank Ch. Eigler]

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

hi -


On Thu, Nov 18, 2004 at 01:22:41PM -0500, Kelley Cook wrote:
> Does someone recall the reason why back in January 2003 the toplevel 
> libtool copied into acinclude.m4?  This seems to be done for a purpose, 
> but I haven't been able to determine what the reason was. [...]

I'm afraid I don't remember the specifics, though I believe I was also
testing on Solaris at that time.

> [...]
> If you delete the 928 line acinclude.m4 and put an ACLOCAL_AMFLAGS=I .. 
> in Makefile.am followed by autoreconf with ac2.59/am1.9.3 [...]

Please go ahead and make the change, especially if you can test it
on a Solaris box.

> [...]
> The new version still bootstraps on i686-pc-cygwin with 
> --enable-libmudflap (though this is probably a poor test as almost every 
> libmudflap test fails under cygwin).

One of these days, I'll sit down with my old Windows laptop ...


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [libmudflap] Why was the toplevel libtool.m4 copied into acinclude.m4?

[Alexandre Oliva]

On Nov 18, 2004, Kelley Cook <kcook@gcc.gnu.org> wrote:

> If you delete the 928 line acinclude.m4 and put an ACLOCAL_AMFLAGS=I
> .. in Makefile.am followed by autoreconf with ac2.59/am1.9.3 it leads
> to the following differences in "configure" compared to the current
> directory simply autoreconf'd with the same versions.

Even if you have a different libtool.m4 in the default aclocal search
path?  If so, using -I .. is fine; otherwise, the sinclude/fake-define
dance is the way to go.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}