undefined macros when running autotools

[JohnPJenkins]

Hi,

I'm building cci from the repository on titan and am running into some undefined macro issues. Autotools versions:

autoconf - 2.69 automake - 1.14 libtool - 2.4.2

And here's the output of autogen.pl:

CCI autogen
[...]
2. Running GNU Autotools...
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I ./config
configure.ac:152: warning: macro 'AM_ENABLE_SHARED' not found in library
configure.ac:153: warning: macro 'AM_DISABLE_STATIC' not found in library
[...]
autoreconf: configure.ac: tracing
autoreconf: configure.ac: adding subdirectory src/openpa to autoreconf
autoreconf: Entering directory `src/openpa'
[...]
autoreconf: Leaving directory `src/openpa'
autoreconf: configure.ac: not using Libtool
configure.ac:152: error: possibly undefined macro: AM_ENABLE_SHARED
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:153: error: possibly undefined macro: AM_DISABLE_STATIC
configure.ac:265: error: possibly undefined macro: AC_PROG_LIBTOOL
autoreconf: /sw/xk6/autoconf/2.69/sles11.1_gnu4.3.4/bin/autoconf failed with exit status: 1

Each of these macros are deprecated, which may have something to do with it?

[JohnPJenkins]

Should clarify - the tarball works fine for configureing - this is just for working off of git.

[scottatchley]

Let me look into this.

On Mar 1, 2016, at 2:00 PM, John Jenkins notifications@github.com wrote:

Should clarify - the tarball works fine for configureing - this is just for working off of git.

— Reply to this email directly or view it on GitHub.

[scottatchley]

On Mar 1, 2016, at 4:42 PM, Atchley, Scott atchleyes@ornl.gov wrote:

Let me look into this.

On Mar 1, 2016, at 2:00 PM, John Jenkins notifications@github.com wrote:

Should clarify - the tarball works fine for configureing - this is just for working off of git.

Hi John,

This works for me on titan. You will need to change stf008 to the project that your account is in.

Scott

From the CCI top source directory on titan:

module load autoconf module load automake module load m4 ./autogen.pl mkdir build-titan cd buid-titan ../configure --prefix=$MEMBERWORK/stf008/cci --with-gni-ptag=251 --with-gni-cookie=0x5430000 --without-verbs --with-sm-xpmem=/opt/cray/xpmem/0.1-2.0502.64982.5.3.gem make && make install

On eos:

no need to regenerate configure, just use it

mkdir build-eos cd build-eos ../configure --prefix=$MEMBERWORK/stf008/cci-eos-test --with-gni-cookie=0xc9df0000 --without-verbs --with-sm-xpmem=/opt/cray/xpmem/0.1-2.0502.64982.5.3.ari make && make install

[JohnPJenkins]

So there was one difference in my env - I additionally had module load libtool. Unloading it and re-running autogen.pl unfortunately led to the same error, though with some extra unrelated warnings. I'll just work off the tarball from here on out. FWIW, here's my current module env:

Currently Loaded Modulefiles:
  1) modules/3.2.10.3
  2) eswrap/1.1.0-1.020200.1231.0
  3) craype-network-gemini
  4) craype/2.4.2
  5) cray-mpich/7.2.5
  6) craype-interlagos
  7) lustredu/1.4
  8) DefApps
  9) site-aprun/1.0
 10) aprun-usage/1.0
 11) altd/1.0
 12) vim/7.4
 13) m4/1.4.16
 14) autoconf/2.69
 15) automake/1.14
 16) cmake/2.8.10.2
 17) boost/1.57.0
 18) gcc/4.9.0
 19) cray-libsci/13.2.0
 20) udreg/2.3.2-1.0502.10518.2.17.gem
 21) ugni/6.0-1.0502.10863.8.28.gem
 22) pmi/5.0.9-1.0000.10911.175.4.gem
 23) dmapp/7.0.1-1.0502.11080.8.74.gem
 24) gni-headers/4.0-1.0502.10859.7.8.gem
 25) xpmem/0.1-2.0502.64982.5.3.gem
 26) dvs/2.5_0.9.0-1.0502.2188.1.113.gem
 27) alps/5.2.4-2.0502.9774.31.12.gem
 28) rca/1.0.0-2.0502.60530.1.63.gem
 29) atp/1.8.3
 30) PrgEnv-gnu/5.2.82

Thanks, John

[scottatchley]

libtool is in /usr. You should not have to load it or specify it on configure.

I have stored my configure at:

/lustre/atlas1/stf008/world-shared/cci-configure

You can copy that to your CCI directory.

On Mar 2, 2016, at 9:40 AM, John Jenkins notifications@github.com wrote:

So there was one difference in my env - I additionally had module load libtool. Unloading it and re-running autogen.pl unfortunately led to the same error, though with some extra unrelated warnings. I'll just work off the tarball from here on out. FWIW, here's my current module env:

Currently Loaded Modulefiles: 1) modules/3.2.10.3 2) eswrap/1.1.0-1.020200.1231.0 3) craype-network-gemini 4) craype/2.4.2 5) cray-mpich/7.2.5 6) craype-interlagos 7) lustredu/1.4 8) DefApps 9) site-aprun/1.0 10) aprun-usage/1.0 11) altd/1.0 12) vim/7.4 13) m4/1.4.16 14) autoconf/2.69 15) automake/1.14 16) cmake/2.8.10.2 17) boost/1.57.0 18) gcc/4.9.0 19) cray-libsci/13.2.0 20) udreg/2.3.2-1.0502.10518.2.17.gem 21) ugni/6.0-1.0502.10863.8.28.gem 22) pmi/5.0.9-1.0000.10911.175.4.gem 23) dmapp/7.0.1-1.0502.11080.8.74.gem 24) gni-headers/4.0-1.0502.10859.7.8.gem 25) xpmem/0.1-2.0502.64982.5.3.gem 26) dvs/2.5_0.9.0-1.0502.2188.1.113.gem 27) alps/5.2.4-2.0502.9774.31.12.gem 28) rca/1.0.0-2.0502.60530.1.63.gem 29) atp/1.8.3 30) PrgEnv-gnu/5.2.82

Thanks, John

— Reply to this email directly or view it on GitHub.

[JohnPJenkins]

Yes - thought I'd mention it as the autotools in /usr/bin are of different versions than the modules, which I suppose is expected :).

Thanks for the configure script, I've grabbed it.

[roblatham00]

sorry John and Scott never fully resolved this. I'm trying to build cci master under the 'spack' package management framework and running into this problem. this is on CentOS release 6.8 (Final)