Linking issue when building GROMACS

[acmnpv]

Hello, I recently ran into a strange linking issue when building GROMACS 2023.3 with AdaptiveCpp 23.10.0

I build ACpp using gcc-12 against the HIP backend (using ROCm 6.0.0), and then followed up building GROMACS using the same GCC.
As expected from the build requirements from ACpp, it pulled in the context and fiber libraries from boost. But when I later tried to run the GROMACS binaries I saw that they also linked against the boost filesystem libraries, which as far as I understand shouldn't be the case as neither GROMACS nor ACpp have those as a requirement.

This actually caused linking errors on one system I tried it on, where it couldn't find and link against boost filesystem automatically, and crashed when forcing the link.

Any ideas about what could be the cause would be welcome. I wasn't able to reproduce the crash on a different system, but the link against boost filesystem was still there.

I already checked with @al42and but he also wasn't sure what the issue could be.

Thanks for your advice!

[illuhad]

Interesting, I think @tom91136 previously mentioned some boost.filesystem dependency that should not be there. IIRC in the discussion with him the consensus was that boost.filesystem is probably transitively pulled in by some dependency of AdaptiveCpp.

Can you check whether boost context/fiber or other libraries that AdaptiveCpp depends on have a dependency on boost.filesystem?

[acmnpv]

I just checked the fiber and context libraries, and neither of them have filesystem as a dependency themselves.

I think the problem is that there is an explicit search for boost filesystem here:

src/common/CMakeLists.txt:17:find_package(Filesystem REQUIRED Final Experimental Boost)

Which means that it will (as far as I understand the FindFilesystem CMake script) prepare to link to boost filesystem, even though it is not an actual project dependency. I think it shouldn't search for boost filesystem in that line, because the project anyhow requires a C++17 compliant compiler and std library, and that should come with std::filesystem :)

[illuhad]

I had assumed this too, but alas, there are many toolchains which in principle have C++17 support, but don't have the filesystem library yet (or need different linking). So the current cmake integration supports std::filesystem, std::experimental::filesystem and boost::filesystem. boost.filesystem should only be required if std::filesystemis not available.

See e.g. #667

[acmnpv]

Of course this was GROMACS that uncovered this 😸

I'll have a look then to see how to prevent linking boost::filesystem if std::filesystem is available, or if the issue was that the cluster I was building on had a broken stdlib installation that caused boost::filesystem to be picked up.

On a related note, will Acpp change to require a compliant stdlib in the future?

GROMACS changed a while back to require std::filesystem to be available (which was a contentious change in itself that I had to push through) and put the pressure on cluster admins to no longer use default software stacks that are decade old by this point.

[illuhad]

Sounds good :)

On a related note, will Acpp change to require a compliant stdlib in the future?

Well, the support for boost.filesystem and std::experimental::filesystem was only intended as a compatibility workaround. I guess we shouldn't be hauling that around for decades ;) I haven't thought about yet when to drop this compatibility support. My current thinking is that in principle it shouldn't hurt to also support these older approaches - assuming the infrastructure functions correctly and does not cause linking problem ;)