summaryrefslogtreecommitdiff
path: root/tests/cve.scm
diff options
context:
space:
mode:
authorCarl Dong <contact@carldong.me>2022-03-01 11:35:17 -0500
committerCarl Dong <contact@carldong.me>2022-03-16 22:13:48 -0400
commit34e9eae68c9583acce5abc4100add3d88932a5ae (patch)
tree6d26dab2514b976fbbce63d543260a9d5b205fbf /tests/cve.scm
parent0c6c957a01c789f055c44c01165a14389dfd4a60 (diff)
downloadguix-patches-34e9eae68c9583acce5abc4100add3d88932a5ae.tar
guix-patches-34e9eae68c9583acce5abc4100add3d88932a5ae.tar.gz
gnu: cross-base: Don't specify mingw --with-newlib
Previous to this commit, we added a --with-newlib configure flag to cross-gcc when cross-newlib?, but cross-newlib? is true only when target-mingw?. It turns out that specifying --with-newlib disables the GLIBCXX_CROSSCONFIG check, which is used to detect _GLIBCXX_HAVE__WFOPEN, which is required in C++17 std::filesystem for mingw-w64 systems. Additional context: In gnu/packages/embedded.scm, --with-newlib is specified explicitly when we're actually using newlib, which seems like the correct way of handling it. Situation in other distros: - Debian's gcc-mingw-w64 doesn't specify --with-newlib - Fedora's mingw64-gcc-c++ explicitly specifies --without-newlib Chesterton's fence: Chatting with janneke, who originally added this mechanism, reveals that this flag is not only no longer required, but also that removing it doesn't break his guile-mingw builds. See IRC logs of #guix for 2022-02-15. * gnu/packages/cross-base.scm (cross-gcc-arguments): Don't check for and specify --with-newlib. (cross-libc): Check for mingw and use mingw-w64 directly. (cross-newlib?): Remove, unexport. (native-libc): Remove.
Diffstat (limited to 'tests/cve.scm')
0 files changed, 0 insertions, 0 deletions