Both compiler packages depend on it already, and its presence makes it
easy to accidentally create build cycles by putting gcc in the
dependency path when it shouldn't be.
Both compiler packages depend on it already, and its presence makes it
easy to accidentally create build cycles by putting gcc in the
dependency path when it shouldn't be.
Both compiler packages depend on it already, and its presence makes it
easy to accidentally create build cycles by putting gcc in the
dependency path when it shouldn't be.
Don't use '-' for specifying versions, use '>=', which isn't ambiguous.
Both compiler packages depend on it already, and its presence makes it
easy to accidentally create build cycles by putting gcc in the
dependency path when it shouldn't be.
Both compiler packages depend on it already, and its presence makes it
easy to accidentally create build cycles by putting gcc in the
dependency path when it shouldn't be.
Both compiler packages depend on it already, and its presence makes it
easy to accidentally create build cycles by putting gcc in the
dependency path when it shouldn't be.
Both compiler packages depend on it already, and its presence makes it
easy to accidentally create build cycles by putting gcc in the
dependency path when it shouldn't be.
openmpi inventes its own version of AC_CONFIG_SUBDIRS, passing $libdir
relatives to $exec_prefix without initialising $exec_prefix will pass
$libdir as NONE/lib{32,64}.
We can't set $exec_prefix relative to $prefix because autotools will
expand the value only twice. See c96738a6e9, (common/gnu-configure-args:
set exec_prefix to ${prefix}, 2021-02-23) and 9bdf2f6e4d, (Revert
"common/gnu-configure-args: set exec_prefix to ${prefix}", 2021-03-05)
