While trying to reinstall an environment that used to work before my last pull (to 008fe37), packages started to break down with errors suggesting that system stuff was leaking into build_env, for example:
$ spack install gmp
==> Executing phase: 'autoreconf'
==> Executing phase: 'configure'
==> Executing phase: 'build'
>> 661 make[2]: *** [addmul_1.lo] Error 63
663 libtool: Version mismatch error. This is libtool 2.4.2, but the
664 libtool: definition of this LT_INIT comes from libtool 2.4.6.
665 libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2
666 libtool: and run autoconf again.git bisect pointed me to 99dfff4 (merged in #13578) that looks like the culprit: when a package being installed depends on perl, the patch in #13578 prepends the concretized perl path to everything else. The issue is that when perl is external, that machinery ends up prepending a system directory (/usr/bin for instance) to $PATH in the build_env thus making the build environment find system stuff over Spack stuff (e.g.: libtool).
$ spack build-env gmp | grep libtool
# ...stuff...
PATH=/usr/bin:/davide/home/userinternal/fficarel/src/spack/lib/spack/env/gcc:/davide/home/userinternal/fficarel/src/spack/opt/spack/linux-centos7-power8le/gcc-4.8.5/libtool-2.4.6-eew4dtszgkcdg27jmfy6p57gk4kgq644/bin:/usr/bin
# ...stuff...
Notice that /usr/bin shows up both as first and last $PATH component.
Steps to reproduce the issue
On a system with a provided libtool < 2.4.6 (older than the default version provided by spack @ 008fe37), the following commands reliably reproduce the issue (any package that has an autoreconf phase and directly depends on libtool will trigger the issue in the same way tho):
$ cat ~/.spack/packages.yaml
packages:
perl:
paths:
perl@5.16.3-host +shared +threads: /usr
buildable: False
$ spack install gmp
==> Executing phase: 'autoreconf'
==> Executing phase: 'configure'
==> Executing phase: 'build'
>> 661 make[2]: *** [addmul_1.lo] Error 63
663 libtool: Version mismatch error. This is libtool 2.4.2, but the
664 libtool: definition of this LT_INIT comes from libtool 2.4.6.
665 libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2
666 libtool: and run autoconf again.Information on your system
$ lsb_release --all
LSB Version: :core-4.1-noarch:core-4.1-ppc64le
Distributor ID: CentOS
Description: CentOS Linux release 7.5.1804 (AltArch)
Release: 7.5.1804
Codename: AltArch
$ cat ~/.spack/packages.yaml
packages:
perl:
paths:
perl@5.16.3-host +shared +threads: /usr
buildable: False
While trying to reinstall an environment that used to work before my last pull (to 008fe37), packages started to break down with errors suggesting that system stuff was leaking into
build_env, for example:git bisectpointed me to 99dfff4 (merged in #13578) that looks like the culprit: when a package being installed depends onperl, the patch in #13578 prepends the concretizedperlpath to everything else. The issue is that whenperlis external, that machinery ends up prepending a system directory (/usr/binfor instance) to$PATHin thebuild_envthus making the build environment find system stuff over Spack stuff (e.g.:libtool).Notice that
/usr/binshows up both as first and last$PATHcomponent.Steps to reproduce the issue
On a system with a provided
libtool < 2.4.6(older than the default version provided byspack@ 008fe37), the following commands reliably reproduce the issue (any package that has anautoreconfphase and directly depends onlibtoolwill trigger the issue in the same way tho):Information on your system