Here is why I have:
 
$ for i in libtool glibtool libtoolize glibtoolize ; do which $i ; done
/usr/bin/libtool
/usr/local/bin/glibtool
/usr/local/bin/glibtoolize

$ /usr/bin/libtool -V
Apple Inc. version cctools-900

$ /usr/local/bin/glibtool --version
glibtool (GNU libtool) 2.4.6
Written by Gordon Matzigkeit, 1996

Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

On Fri, Dec 8, 2017 at 1:30 PM, Kenneth Raffenetti <raffenet@mcs.anl.gov> wrote:
Does 'which libtoolize' or 'which glibtoolize' return a valid program? It looks like we could do a better job or returning an error when they aren't even found. At the moment these errors go unnoticed:

  > usage: dirname path

Ken


On 12/08/2017 02:00 PM, Jeff Hammond wrote:
merely reverting the change on the most pertinent lines doesn't solve the problem.  i'm not sure what the fix is.

jrhammon-mac01:git jrhammon$ git diff
diff --git a/autogen.sh b/autogen.sh
index 4036565be..eda353652 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -304,7 +304,12 @@ if [ -n "$autotoolsdir" ] ; then
          automake=$autotoolsdir/automake
          autom4te=$autotoolsdir/autom4te
          aclocal=$autotoolsdir/aclocal
-        libtoolize=$autotoolsdir/libtoolize
+        #libtoolize=$autotoolsdir/libtoolize
+        if [ -x "$autotoolsdir/glibtoolize" ] ; then
+            libtoolize=$autotoolsdir/glibtoolize
+        else
+            libtoolize=$autotoolsdir/libtoolize
+        fi
         AUTOCONF=$autoconf
         AUTOHEADER=$autoheader
@@ -332,7 +337,12 @@ else
      autom4te=${AUTOM4TE:-autom4te}
      automake=${AUTOMAKE:-automake}
      aclocal=${ACLOCAL:-aclocal}
-    libtoolize=${LIBTOOLIZE:-libtoolize}
+    #libtoolize=${LIBTOOLIZE:-libtoolize}
+    if [ -x "$autotoolsdir/glibtoolize" ] ; then
+        libtoolize=$autotoolsdir/glibtoolize
+    else
+        libtoolize=$autotoolsdir/libtoolize
+    fi
  fi
  ProgHomeDir $autoconf   autoconfdir
jrhammon-mac01:git jrhammon$ ./autogen.sh

####################################
## Checking user environment
####################################

Verifying the location of autogen.sh... done
usage: dirname path
Checking if autotools are in the same location... no
autoconf is in /usr/local
automake is in /usr/local
libtool  is in /
===> WARNING: Autotools are in different locations. In rare occasion,
===> WARNING: resulting configure or makefile may fail in some unexpected ways.
Checking if autoreconf accepts -I //share/aclocal... no
Checking if autoreconf works after an additional /libtoolize step... no
===> ERROR:   Since none of the autoreconf workaround works
===> ERROR:   and autotools are not in the same directory, aborting...
===> ERROR:   Updating autotools or putting all autotools in the same location
===> ERROR:   may resolve the issue.

On Fri, Dec 8, 2017 at 11:54 AM, Kenneth Raffenetti <raffenet@mcs.anl.gov <mailto:raffenet@mcs.anl.gov>> wrote:

    Hmm, I suppose we didn't run into this on our test systems since we
    always install those tools from scratch, and I'm still not a Mac guy
    so I didn't notice :). I'll put together a PR to revert it.

    Ken


    On 12/08/2017 09:27 AM, Bland, Wesley wrote:

        I guess posting the link to our GitHub Enterprise instance
        doesn't help. Here's the correct link:

        https://github.com/pmodels/mpich/commit/a512f954007fefa4b3b218848854481927422fc3
        <https://github.com/pmodels/mpich/commit/a512f954007fefa4b3b218848854481927422fc3>

            On Dec 8, 2017, at 9:24 AM, Bland, Wesley
            <wesley.bland@intel.com <mailto:wesley.bland@intel.com>> wrote:

            This would appear to be the culprit. Maybe Pavan/Ken can
            talk about why it was removed?

            https://github.intel.com/csr/mpich-ofi/commit/a512f954007fefa4b3b218848854481927422fc3
            <https://github.intel.com/csr/mpich-ofi/commit/a512f954007fefa4b3b218848854481927422fc3>

                On Dec 7, 2017, at 3:51 PM, Jeff Hammond
                <jeff.science@gmail.com <mailto:jeff.science@gmail.com>>

                wrote:

                autogen.sh is failing for me on Mac because Apple's
                libtool is not in the same place as Homebrew's
                autoconf/automake.  I perused autogen.sh but didn't see
                an option to fix this.

                I need to use Homebrew autotools for other projects and
                don't want to uninstall Xcode for obvious reasons.  Is
                there a workaround besides hacking autogen.sh and hating
                myself?  I'd like to cause it to glibtool instead.

                If nothing else, autogen.sh incorrectly prints the
                location of libtool.  It is in /usr/bin not /.

                Thanks,

                Jeff

                jrhammon-mac01:git jrhammon$ which libtool
                /usr/bin/libtool
                jrhammon-mac01:git jrhammon$ which autoconf
                /usr/local/bin/autoconf
                jrhammon-mac01:git jrhammon$ which automake
                /usr/local/bin/automake
                jrhammon-mac01:git jrhammon$ which glibtool
                /usr/local/bin/glibtool


                jrhammon-mac01:git jrhammon$ ./autogen.sh

                ####################################
                ## Checking user environment
                ####################################

                Verifying the location of autogen.sh... done
                usage: dirname path
                Checking if autotools are in the same location... no
                autoconf is in /usr/local
                automake is in /usr/local
                libtool  is in /
                ===> WARNING: Autotools are in different locations. In
                rare occasion,
                ===> WARNING: resulting configure or makefile may fail
                in some unexpected ways.
                Checking if autoreconf accepts -I //share/aclocal... no
                Checking if autoreconf works after an additional
                libtoolize step... no
                ===> ERROR:   Since none of the autoreconf workaround works
                ===> ERROR:   and autotools are not in the same
                directory, aborting...
                ===> ERROR:   Updating autotools or putting all
                autotools in the same location
                ===> ERROR:   may resolve the issue.


                --
                Jeff Hammond
                jeff.science@gmail.com <mailto:jeff.science@gmail.com>
                <mailto:jeff.science@gmail.com
                <mailto:jeff.science@gmail.com>>
                http://jeffhammond.github.io/
                _______________________________________________
                To manage subscription options or unsubscribe:
                https://lists.mpich.org/mailman/listinfo/devel
                <https://lists.mpich.org/mailman/listinfo/devel>





        _______________________________________________
        To manage subscription options or unsubscribe:
        https://lists.mpich.org/mailman/listinfo/devel
        <https://lists.mpich.org/mailman/listinfo/devel>

    _______________________________________________
    To manage subscription options or unsubscribe:
    https://lists.mpich.org/mailman/listinfo/devel
    <https://lists.mpich.org/mailman/listinfo/devel>




--
Jeff Hammond
jeff.science@gmail.com <mailto:jeff.science@gmail.com>
http://jeffhammond.github.io/


_______________________________________________
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/devel




--