* Richard W. M. Jones: > We noticed that some ghc-* packages FTBFS with Modern C failures eg > these two picked at random: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=113534568 > https://koji.fedoraproject.org/koji/taskinfo?taskID=113534602 > > I think what's happening here is that ghc is generating C FFI code > which is fed to GCC 14. The code being generated is buggy. > > So probably the fix for this is just in ghc itself. I looked at > upstream ghc and wasn't able to identify any commits which fix this > (except maybe > https://github.com/ghc/ghc/commit/b3a3534b6f75b34dc4db76e904e071485da6d5cc). > But I didn't look especially hard and the code is very complicated. > > An alternative to fixing this in the compiler is to throw up our hands > and add: > > %global build_type_safety_c 0 > > to every affected ghc-* package. Please don't do this, it's unnecessary busy-work. > eg This fixes ghc-readline: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=113535426 > > Any thoughts on this? If GHC cannot be fixed properly, it should be trivial to teach it to emit #pragma directives near the start of the generated files. This is what we currently do for Vala: <https://src.fedoraproject.org/rpms/vala/blob/rawhide/f/vala-c99.patch> (The upstream submission has a Clang variant as well.) Hopefully, GHC has a better understanding of the types and the control flow of the code it generates than the Vala compiler, so this shouldn't be necessary. For the first issue, please try this GHC patch (only compile-tested with the stage 0 compiler build this point): diff --git a/compiler/GHC/HsToCore/Foreign/C.hs b/compiler/GHC/HsToCore/Foreign/C.hs index 2164ded112..8beaa8986e 100644 --- a/compiler/GHC/HsToCore/Foreign/C.hs +++ b/compiler/GHC/HsToCore/Foreign/C.hs @@ -560,7 +560,7 @@ mkFExportCBits dflags c_nm maybe_target arg_htys res_hty is_IO_res_ty cc , ppUnless res_hty_is_unit $ if libffi then char '*' <> parens (ffi_cResType <> char '*') <> - text "resp = cret;" + text "resp = " <> parens ffi_cResType <> text "cret;" else text "return cret;" , rbrace ] I'm not even sure if there is a better fix for this. Perhaps emitting a memcpy call to avoid the aliasing violation? For the second build failure, GCC reports *genuine* bugs in the C code in that package, leading to run-time crashes: cbits/hslibxml-shim.c:44:21: error: warning: incompatible implicit declaration of built-in function ‘calloc’ [-Wbuiltin-declaration-mismatch] 44 | user_data = calloc(1, sizeof(UserData)); | ^~~~~~ That hasn't been valid C since 1986 or thereabouts. As Jakub said, you really need to include the appropriate header files to make this work. Thanks, Florian -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
