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)
Érico Rolim
Evgeny Ermakov
Đoàn Trần Công Danh
Philipp David
AviKav
UsernameRandomlyGenerated
Nicolo
FollieHiyuki
Roberto Ricci
Arda Demir
Stefano Ragni
tibequadorian
Cameron Nemo
Paper
mobinmob
Benjamín Albiñana
David Anguita
Caleb Gingles
glaulher