Bug Report: Missing headers in camp and mfem building over Ascent tags/v0.9.0-0.9.2

[timohyva]

I am on a Cray SUSE 15 enterprise cluster with crayPE/24.03. I was using build _ascent.sh to build dependencies with mpich and gcc/13.2.

It appears that

• camp-2022.10.1/include/camp/resource/host.hpp miss #include <cstdlib>
• camp-2022.10.1/include/camp/resource.hpp miss #include <stdexcept>
• mfem-4.5.2/general/hash.hpp and mfem-4.5.2/general/mem_manager.cpp miss #include <cstdint>

The error messages typically are

camp-2022.10.1/include/camp/resource/host.hpp:65:71: error: ‘free’ was not declared in this scope
   65 |       void deallocate(void *p, MemoryAccess = MemoryAccess::Device) { free(p); }
...
camp-2022.10.1/include/camp/resource/host.hpp:57:27: error: ‘malloc’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation
   57 |         return (T *)malloc(sizeof(T) * n);
...
mfem-4.5.2/general/hash.hpp:1001:39: error: ‘uint64_t’ was not declared in this scope
 1001 |       auto k = reinterpret_cast<const uint64_t &>(*begin);
...
mfem-4.5.2/general/mem_manager.cpp:268:10: error: ‘uintptr_t’ does not name a type
  268 |    const uintptr_t addr = (uintptr_t) ptr;
...

These missing headers appear over Ascent/v0.9.0-0.9.2 building scripts. After manually access these source files and adding missing headers, camp and mfem can been built successfully, so does Ascent.

I have red this closed issue #1259, it looks just same problem as I get. I wonder does it solved also for tags? I checkout tags/v0.9.x to get release. Is this good practice?

[cyrush]

@timohyva #1259 resolved an issue with camp, to resolve a few gcc mfem issues I think we need to use the mfem 4.7 release.

That said Ascent 0.9.3 is using MFEM 4.6.x. Have you tried 0.9.3?

We do not resolve build issues for older releases, we fix build patterns and scripts and create new releases.

[timohyva]

I don't build 0.9.3 yet, may be I should find time to try it out and see what it turns out.

Or could I just modify version number of mfem to 4.7 in build_ascent.sh, will it induces problem related to old/new APIs between dependencies and Ascent?

[cyrush]

I believe that mfem 4.7 will work with Ascent 0.9.3, based on: #1393

In general: due to libs making API changes - mixing and matching TPLs may cause issues.
This is why we share what versions we are using for each release:

https://github.com/Alpine-DAV/ascent/blob/develop/CHANGELOG.md

[timohyva]

I didn't know Ascent devs provide changlog, looks like it provides clear track of dependencies' version.

If I understand right, the versions which aren't mentioned under Preferred dependency versions for Ascent@... are same as they are in earlier version of Ascent, right? I find it takes quite a bit time to trace down exactly which version of dependency one suppose to use.

I will give feedback after I try out v0.9.3.

[cyrush]

@timohyva sorry for the delay.

I we don't explicitly have pinned versions there is more flexibility.
That said, the build_ascent script always reflects what we have tested with.

Let us know if you see any additional issues with 0.9.3 builds, we will be working on TPL updates for 0.9.4 in January 2025.