dev-lang/php: Fix implicit declaration of function '__c11_atomic_load' #35210
Conversation
This is observed with GCC14 and upstream commit[0] fixing the bug is merged only in RC branches. [0]: https://github.com/php/php-src/commit/72526609413e8a8cd768ed4966c17b1a9db6c12c.patch Signed-off-by: Brahmajit Das <brahmajit.xyz@gmail.com>
Pull Request assignmentSubmitter: @listout dev-lang/php: Linked bugsNo bugs to link found. If your pull request references any of the Gentoo bug reports, please add appropriate GLEP 66 tags to the commit message and request reassignment. If you do not receive any reply to this pull request, please open or link a bug to attract the attention of maintainers. In order to force reassignment and/or bug reference scan, please append Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide |
gentoo-bot
added
assigned
Pull request CI reportReport generated at: 2024-02-07 09:52 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
|
Thanks! Since these are build fixes, I think we can apply them directly to php-8.2.15.ebuild and php-8.3.2.ebuild (without an |
|
@orlitzky We might need a revision bump for error/build failure like there, for reference https://wiki.gentoo.org/wiki/Modern_C_porting#Is_this_cosmetic.3F |
|
Yes, if the patch fixes a crash on GCC 13 in addition to a compilation failure on GCC 14 (and ModernC failures are at best a potential crash and at worst a guaranteed !amd64 crash) then a revbump is appropriate. For something like filter-lto I likely wouldn't revbump, as existing built packages without LTO in your make.conf flags shouldn't be crashy and actual LTO users wouldn't be able to build the package to begin with. |
|
Ok, better safe than sorry. I forgot that php-.8.2.15 is stable on one arch already too. Thanks. |
This is observed with GCC14 and upstream commit0 fixing the bug is merged only in RC branches.