More of a question than issue, FindHwloc.cmake vs FindHWLOC.cmake
Opened this issue · 8 comments
I am questioning the timing of this fork since FindHwloc.cmake was "modernized" with FindHWLOC.cmake. Should this be "reforked" with updates in the master of https://github.com/kassonlab/gmxapi?
I think this trickles down to also needing to change/update hardwaretopology.cpp because of linking errors with hwloc and new MacOS chips. I was getting Undefined symbols for architecture x86_64 specifically realted to hwloc and hardwaretopology.cpp.
Regardless still getting errors for cmi_* functions when linking. Why is the cmi_ in the function prefix when functions in hardwaretopology.cpp don't even start with that, like for instance hwloc_distances_get
[ 98%] Linking CXX shared library ../../lib/libgromacs.dylib
Undefined symbols for architecture x86_64:
"_cmi_hwloc_distances_get", referenced from:
gmx::HardwareTopology::detect() in hardwaretopology.cpp.o
"_cmi_hwloc_distances_release", referenced from:
gmx::HardwareTopology::detect() in hardwaretopology.cpp.o
"_cmi_hwloc_get_api_version", referenced from:
gmx::HardwareTopology::detect() in hardwaretopology.cpp.o
"_cmi_hwloc_get_nbobjs_by_depth", referenced from:
gmx::HardwareTopology::detect() in hardwaretopology.cpp.o
"_cmi_hwloc_get_obj_by_depth", referenced from:
gmx::HardwareTopology::detect() in hardwaretopology.cpp.o
"_cmi_hwloc_get_type_depth", referenced from:
gmx::HardwareTopology::detect() in hardwaretopology.cpp.o
"_cmi_hwloc_obj_type_is_dcache", referenced from:
gmx::HardwareTopology::detect() in hardwaretopology.cpp.o
"_cmi_hwloc_topology_destroy", referenced from:
gmx::HardwareTopology::detect() in hardwaretopology.cpp.o
"_cmi_hwloc_topology_init", referenced from:
gmx::HardwareTopology::detect() in hardwaretopology.cpp.o
"_cmi_hwloc_topology_is_thissystem", referenced from:
gmx::HardwareTopology::detect() in hardwaretopology.cpp.o
"_cmi_hwloc_topology_load", referenced from:
gmx::HardwareTopology::detect() in hardwaretopology.cpp.o
"_cmi_hwloc_topology_set_io_types_filter", referenced from:
gmx::HardwareTopology::detect() in hardwaretopology.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [lib/libgromacs.5.0.0.dylib] Error 1
make[1]: *** [src/gromacs/CMakeFiles/libgromacs.dir/all] Error 2
make: *** [all] Error 2
This fork originally supported gmxapi 0.0.4 before full support was included in GROMACS 2019. If it no longer builds in common environments, maybe we should remove it or just put a note redirecting to https://gitlab.com/gromacs/gromacs/
@peterkasson do you have a preference?
I'm sorry; my earlier response didn't do anything to help resolve the issue.
@BJWiley233 is it acceptable and effective for you to use an official GROMACS release? Current documentation for the Python package installation with links to GROMACS installation instructions can be found at https://manual.gromacs.org/current/gmxapi/userguide/install.html
Thank you for reminding us of the staleness of this repository.
Yes sorry I didn't respond. I started to then got side tracked. I just cd python_packaging/src and python setup.py install, after installing requirements of course, since with my conda installation they don't want you to use pip.
I'm sorry, but at this point I can't remember what distinctions remain (if any) between this repository and the official GROMACS 2019 release. Have you tried building from the official release?
The GROMACS project is no longer accepting patches for build system problems with GROMACS 2019 or 2020.
Do you need GROMACS 2019? GROMACS 2022 should be out on Friday, and I highly recommend GROMACS 2022 + gmxapi 0.3.
You should still be able to use pip install with conda, but you will need the conda-friendly tool chain, including the conda version of pip, and compilers that produce binaries compatible with both the mpi4py package and the GROMACS installation. However, you can download the source archive for any gmxapi release by choosing from https://pypi.org/project/gmxapi/#history and clicking on "Download files".
I could probably do the update. I just wanted to see if I could get it to work with my current 2021.2 download.
GROMACS 2021.2 is still supported. If you are having trouble building an official 2021.2 release, please ask on the forums or open a GROMACS issue
To install gmxapi 0.2 or 0.3 for GROMACS 2021.2, you should be able to just source your GMXRC and then do pip install gmxapi (optionally specifying a specific gmxapi version requirement).