Boost build broken by looking for a suffix which does not exist

[mboisson]

trafficstars

In the boost.py EasyBlock, this code was added recently by @branfosj, @lexming and @boegel

>         lib_mt_suffix = '-mt'
>         # MT libraries gained an extra suffix from v1.69.0 onwards
>         if LooseVersion(self.version) >= LooseVersion("1.69.0"):
>             if get_cpu_architecture() == AARCH64:
>                 lib_mt_suffix += '-a64'
>             elif get_cpu_architecture() == POWER:
>                 lib_mt_suffix += '-p64'
>             else:
>                 lib_mt_suffix += '-x64'
>
285c297
<             custom_paths['files'].append(os.path.join('lib', 'libboost_thread-mt.%s' % shlib_ext))
---
>             custom_paths['files'].append(os.path.join('lib', 'libboost_thread%s.%s' % (lib_mt_suffix, shlib_ext)))
288c300
<             custom_paths['files'].append(os.path.join('lib', 'libboost_mpi-mt.%s' % shlib_ext))
---
>             custom_paths['files'].append(os.path.join('lib', 'libboost_mpi%s.%s' % (lib_mt_suffix, shlib_ext)))

The -x64 suffix does not exist for us in our installation of Boost 1.72.0. Where is this supposed to have come from ?

[mboisson]

[mboisson@build-node lib]$ pwd
/cvmfs/soft.computecanada.ca/easybuild/software/2020/avx2/Compiler/intel2020/boost/1.72.0/lib
[mboisson@build-node lib]$ ls libboost_thread*
libboost_thread.a  libboost_thread-mt.a  libboost_thread-mt.so  libboost_thread-mt.so.1  libboost_thread-mt.so.1.72 
 libboost_thread-mt.so.1.72.0  libboost_thread.so  libboost_thread.so.1  libboost_thread.so.1.72  libboost_thread.so.1.72.0

[mboisson]

This is the commit that broke the easyblock for us, done by @lexming https://github.com/easybuilders/easybuild-easyblocks/commit/6b883740af2c0e9d6956f0915ec2e4f235f32aa2#diff-2aa6a992f8ba62b416ee4cae734425f3121fa4d6887cdbf623dcb7bf2db8c59f

[Flamefire]

Double checking the boost sources this shouldn't occur when --layout=tagged is used. For reference can you attach your EC and the build log? And have you modified the EasyBlock somehow?

For reference: Boost-1.74.0-GCC-10.2.0.eb works as expected. The upstream 1.72 EC does not use boost_multi_thread=True and hence doesn't run into this check.

[mboisson]

The recipes we use are here : https://github.com/ComputeCanada/easybuild-easyconfigs/blob/computecanada-main/easybuild/easyconfigs/b/Boost/Boost-1.72.0-GCC-9.3.0.eb (for boost without MPI) https://github.com/ComputeCanada/easybuild-easyconfigs/blob/computecanada-main/easybuild/easyconfigs/b/Boost/Boost-1.72.0-gompi-2020a.eb (for boost with MPI)

and our EasyBlock is https://github.com/ComputeCanada/easybuild-easyblocks/blob/computecanada-main/easybuild/easyblocks/b/boost.py

We have the following diff :

         if self.cfg['boost_multi_thread']:
             self.log.info("Building boost with multi threading")
-            taggedversion = ""
-            if LooseVersion(self.version) >= LooseVersion("1.69.0"):
-                # keep 1.66 layout to avoid having -x64 in library names which can confuse cmake
-                taggedversion = "-1.66"
-            self.build_boost_variant(bjamoptions + " threading=multi --layout=tagged" + taggedversion, paracmd)
+            self.build_boost_variant(bjamoptions + " threading=multi --layout=tagged", paracmd)

         # if both boost_mpi and boost_multi_thread are enabled, build boost mpi with multi-thread support
         if self.cfg['boost_multi_thread'] and self.cfg['boost_mpi']:
             self.log.info("Building boost_mpi with multi threading")
-            extra_bjamoptions = (" --user-config=user-config.jam --with-mpi threading=multi --layout=tagged" +
-                                 taggedversion)
+            extra_bjamoptions = " --user-config=user-config.jam --with-mpi threading=multi --layout=tagged"
             self.build_boost_variant(bjamoptions + extra_bjamoptions, paracmd)

[mboisson]

So I guess, from the diff, that we chose to avoid having -x64 because it causes issues with CMake, while upstream decided to keep -x64...

[Flamefire]

So this is not an issue with the upstream EasyBlock but only with yours: You changed the build to not add the suffix but did not change the sanity check to not check for the suffix. So solution: Change your EasyBlocks sanity check.

FTR: Newer CMake versions (3.13+) correctly find boost versions with this suffix: https://gitlab.kitware.com/cmake/cmake/-/blob/v3.13.0/Modules/FindBoost.cmake So I'd say you could revert your EasyBlock changes, but that's up to you of course

[mboisson]

Yeah, our change was there before the extra sanity check was added. That's why it showed up as the extra check "broke" our build. Clearly this is something we can resolve on our side anyway.

[Flamefire]

If you are really keen on that removal of -x64 why not do it in a hook which creates symlinks?

[akesandgren]

@mboisson Take a look at https://github.com/easybuilders/easybuild-easyblocks/pull/2456 since this changes things again.