Hi,
I realized the dummy toolchain option, and was able to get the building going.
I now get a different error:
~~~
$ module add ...
$ eb CP2K-4.1-intel-2016b.eb -r
--filter-deps=Autotools,binutils,flex,GCCcore,GMP,libmatheval,libtool,M4,pkg-config,zlib
--try-toolchain=dummy,dummy
== FAILED: Installation ended unsuccessfully (build directory:
/home/user/tools/easybuild/build/Libint/1.1.6/dummy-dummy): build failed (first 300 chars): cmd "aclocal -I
lib/autoconf && libtoolize && autoconf && ./configure
--prefix=/home/user/tools/easybuild/software/Libint/1.1.6 --enable-deriv --enable-r12 --enable-shared --with-pic
" exited with exitcode 1 and output:
aclocal: warning: autoconf input should be named 'configure.ac', n
== Results of the build can be found in the log file(s)
/tmp/eb-kHDJem/easybuild-Libint-1.1.6-20170929.173815.GjjIz.log
ERROR: Build of /tmp/eb-kHDJem/tweaked_dep_easyconfigs/Libint-1.1.6.eb failed (err: 'build failed (first 300
chars): cmd "aclocal -I lib/autoconf && libtoolize && autoconf && ./configure
--prefix=/home/user/tools/easybuild/software/Libint/1.1.6 --enable-deriv --enable-r12 --enable-shared --with-pic
" exited with exitcode 1 and output:\naclocal: warning: autoconf input should be named \'configure.ac\', n')
~~~
This looks like a warning not an error; if I go to the temporary build directory
and run that command, I see this warning but a proper `configure` script is
still generated. Is there a way to work around this issue?
Thanks,
Roc
On 9/29/2017 4:39 PM, [email protected] wrote:
Hi Kenneth,
That makes a lot of sense. It also led me to more RTFM. I wanted to utilize our
existing module system on the HPC system as much as possible (to save on compile
time and space), so I opted for your third suggestion. However, it looks like
the direct dependencies of CP2K all need to be compiled, which means I would
have to follow the chain and modify the dependencies of the direct dependencies
to use external modules? This doesn't seem a clean and sustainable approach. I
then tried using
`--filter-deps=Autotools,binutils,flex,GCCcore,GMP,icc,iccifort,ifort,imkl,impi,intel,libtool,M4,pkg-config,zlib`
to exclude all the things I can `module add`. The dry-run seems to indicate this
is what I want, with only one exception: intel/2016b. The compiler toolchain
isn't listed as dependency, so it wasn't filtered by `--filter-dep`, and while
building it complained that `intel/2016b` conflicted with the module I loaded:
~~~
== FAILED: Installation ended unsuccessfully (build directory:
/home/user/tools/easybuild/build/intel/2016b/dummy-dummy): build failed (first
300 chars): intel/2016b(2
3):ERROR:150: Module 'intel/2016b' conflicts with the currently loaded
module(s) 'intel/2016/update3'
== Results of the build can be found in the log file(s)
/tmp/eb-e83z38/easybuild-intel-2016b-20170929.162613.JEywY.log
ERROR: Build of
/home/user/tools/easybuild/software/EasyBuild/3.4.0/lib/python2.7/site-packages/easybuild_easyconfigs-3.4.0-py2.7.egg/easybuild/easyconfigs/i/intel/int
el-2016b.eb failed (err: "build failed (first 300 chars): intel/2016b(23):ERROR:150:
Module 'intel/2016b' conflicts with the currently loaded module(s)
'intel/2016/update3'")
~~~
Is there a way to use external compiler module to satisfy the compiler toolchain
as well?
Thanks,
Roc
On 9/29/2017 3:12 PM, Kenneth Hoste wrote:
Dear Roc,
I think your problem is that you have a binutils/2.26 already available on your
system, and 'eb' is assuming it was installed with EasyBuild...
All modules generated with EasyBuild define an environment variable like
$EBROOT<NAME>, where <NAME> is the software name in capitals.
EasyBuild relies on this later when the modules for dependencies are being
loaded, the 'get_software_root' function picks up $EBROOT*.
I think you have three options:
* don't have modules not built with EasyBuild "in view" when installing
software with EasyBuild, i.e. clean up $MODULEPATH first
* reinstalling the binutils/2.26 module with EasyBuild so it is happy, using "eb
binutils-2.26.eb --force"; whether this is an option depends on whether or not that
binutils module is in use already
* inform EasyBuild about this "external module" so it can pick it up and use
it, see http://easybuild.readthedocs.io/en/latest/Using_external_modules.html
regards,
Kenneth
