Installation issue: gperftools when `build_system=cmake` about spack

[msimberg]

Thanks @Chrismarsh! Just linking this for reference, confirming @albestro's comment about CMake being "best-effort" (gperftools/gperftools#1518 (comment)):

But also, yes, having any 3rd-party system relying on our cmake support is a bug in that 3rd party system (and makes me start wondering if I should regret this entire cmake business)

I think we can keep the CMake build system as default as long as it doesn't lead to too many further issues, and we know that we shouldn't expect fixes to the CMake build system.

[wdconinc]

Maintainers: @albestro @eschnett @msimberg @teonnik

[albestro]

Considering the message printed by gperftools when configuring using CMake

CMake Warning at CMakeLists.txt:1486 (message):
  note: gperftools' cmake support is incomplete and is best-effort only

it might be an option to change the default to autotools.

[Chrismarsh]

@msimberg I have now

[Chrismarsh]

Thanks for that. Also my logs are missing, attached here:
spack-build-env.txt
spack-build-out.txt

[msimberg]

I can't test if this helps (because I'm not on a mac, and it builds ok on linux), but it may also help to disable building benchmarks (and perhaps tests as well, since they seem to be enabled by default):

diff --git a/var/spack/repos/builtin/packages/gperftools/package.py b/var/spack/repos/builtin/packages/gperftools/package.py
index 144ac5ddc8..7ec0d3e531 100644
--- a/var/spack/repos/builtin/packages/gperftools/package.py
+++ b/var/spack/repos/builtin/packages/gperftools/package.py
@@ -68,6 +68,7 @@ def cmake_args(self):
             ),
             self.define_from_variant("GPERFTOOLS_BUILD_DEBUGALLOC", "debugalloc"),
             self.define_from_variant("gperftools_enable_libunwind", "libunwind"),
+            self.define("gperftools_build_benchmark", False),
+            self.define("BUILD_TESTING", False),
         ]

I don't know if that just postpones the failure, and it obviously doesn't fix the underlying issue, but may be worth trying? It might be a good idea to report this upstream, even if it's "best-effort".

[haampie]

We moved from autotools to cmake in fd68f89 because of accidental linking to system libunwind.

However, since 82df0e5 that may no longer be an issue.

[Chrismarsh]

@msimberg I can confirm that resolves the build issue for me. I built a little toy program and linked in the allocator and it "Seemed To Work For Me" without a segfault. I think this is a better than reverting to autotools. To @albestro's point I note that the cmake build doesn't seem to produce any cmake config files :(

[msimberg]

@Chrismarsh nice, thanks for checking. I think that's a useful change to make in any case so I've opened #44336. Would you like to report this upstream as well?