[Bug 265684] net/mpich: Fails to build when devel/uthash is installed
Date: Tue, 03 Jan 2023 18:18:06 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265684 John Hein <jcfyecrayz@liamekaens.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #239236| |maintainer-approval? Flags| | --- Comment #2 from John Hein <jcfyecrayz@liamekaens.com> --- Created attachment 239236 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=239236&action=edit [patch] fix mpich to avoid build breakage when the devel/uthash port is installed This is still a problem with the latest ports versions of mpich (3.4.3) and uthash (2.3.0). Attached is a patch to help the mpich build avoid pollution from installed packages in ${LOCALBASE}. The underlying issue: Using 'configure --with-libfabric=${LOCALBASE}' causes CPPFLAGS variables in the generated Makefiles to have -I${LOCALBASE}/include very early - specifically before -I flags that point to the mpich directories in ${WRKSRC}. If the ports version of devel/uthash is installed, this will cause the build to use the devel/uthash version of uthash.h - recall that corresponds to uthash 2.3.0. That uthash.h is not compatible with the mpich code that uses uthash - the mpich bundled version of uthash is 2.0.2, and there are some API incompatibilities between 2.0.2 and 2.3.0 (specifically different parameters expected for the HASH_ADD macro). This patch creates a sym link in ${WRKDIR} to point to the libfabric include files (in ${LOCALBASE}/include/rdma) uses --with-libfabric-include to point to that ${WRKDIR}/include directory. This avoids the early addition of -I${LOCALBASE}/include to CPPFLAGS. Other possible fixes: - change mpich configure scripts to move -I${LOCALBASE}/include (from --with-libfabric) later in CPPFLAGS. - update mpich source code to work with the newer version of uthash - build mpich with the bundled version of libfabric instead of the ports version (net/libfabric) The first option (change configure scripts) is more work than the simple "sym link isolation" workaround used in the patch. I tried implementing that - it wasn't easy to find a fix. Maybe there is a clean / simple way to move the libfabric configuration later in the configure process. The second option (update mpich code for newer uthash) might be something that upstream could be convinced to do or fed and accepted to upstream. Or the mpich code could be made to work with either the older or newer uthash - that's even more complicated and would involve more 'configure' time work. But any of that work to update mpich for a newer uthash is fragile - the next time the freebsd devel/uthash port is updated, that could break mpich again. Note that the HASH_ADD invocation is header-only, so I believe there's no dependency on the uthash library. I did not do an exhaustive analysis, however. ldd says there is no dependency on libuthash in the installed mpich programs / libraries. The last option above (use the bundled libfabric) seems like a reasonable alternative if the attached patch is not desirable for some reason. Yes, it will bloat the mpich installation somewhat (I did not calculate how much), but it does isolate mpich from changes to the net/libfabric port (with all the related pros / cons of that isolation). QA: - portlint (no new warnings) - portclippy (no new suggested format fixes) - poudriere (ok - builds/installs with patch even if devel/uthash is installed first) Ting-Wei Lan, please try the patch, and report if it solves your build failure. -- You are receiving this mail because: You are the assignee for the bug.