Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

undefined macros when running autotools #37

Open
JohnPJenkins opened this issue Mar 1, 2016 · 7 comments
Open

undefined macros when running autotools #37

JohnPJenkins opened this issue Mar 1, 2016 · 7 comments

Comments

@JohnPJenkins
Copy link

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
Copy link
Author

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

@scottatchley
Copy link
Contributor

Let me look into this.

On Mar 1, 2016, at 2:00 PM, John Jenkins [email protected] 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
Copy link
Contributor

On Mar 1, 2016, at 4:42 PM, Atchley, Scott [email protected] wrote:

Let me look into this.

On Mar 1, 2016, at 2:00 PM, John Jenkins [email protected] 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
Copy link
Author

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
Copy link
Contributor

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 [email protected] 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
Copy link
Author

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
Copy link

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants