[Bug 265684] net/mpich: Fails to build when devel/uthash is installed

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.