Created attachment 247581 [details] patch The new clang 17 in main breaks the build of python on armv7
Build failure: http://ampere2.nyi.freebsd.org/data/main-armv7-default/p4be48457f87b_s4347ef6050/logs/errors/python311-3.11.7.log
Hello, I've the same issues. It looks like clang generates a bad address compiling ./Programs/_freeze_module. However simply disabling LTO as it is done for riscv64 alleviates the probem. Please consider the following alternative patch.
Created attachment 248091 [details] no lto on armv7
Sounds like a better approach to me. Did you test it on main?
Yes, it works on main as of 2024-01-24 15.0-CURRENT 1500012 (clang/llvm 17.0.6), ports main tree of around the same date. Whereas, without that patch, the same failure as reported by you is exhibited.
Thanks, we just need approval from python@ or two weeks..
(In reply to Brad Davis from comment #6) Build fix is covered by portmgr blanket approval Approved by: portmgr (build fix blanket)
Not seeing this on 13.2-RELEASE armv7 at least, so I'm not entirely sold on a blanket disabling of LTO here.
(In reply to Charlie Li from comment #8) Is it on real armv7 hw or aarch64 or qemu?
Created attachment 248117 [details] no lto armv7 on current llvm17
(In reply to Charlie Li from comment #8) I doubt that anyone would be using python on armv7 in any performance sensitive setup. Anyway, if it is important, please then consider the last patch which only disables lto on CURRENT after the llvm17 merge. (if/when llvm17 is backported to other branchs, the version guard should probably be revisited. ditto if/when llvm18 is merged with current). (In reply to Mikael Urankar from comment #9) In my case it occurs on an armv7 poudriere jail running on aarch64/rockpro64. For the bug reporter, I believe that the situation is the same except that the host is some of Ampere donated host. Thanks for the feedback!
So llvm17 has been merged to 13-stable and 14-stable, therefore and to my understanding it will likely end up in 13.3 and 14.1 as well. I don't have the mean to test both 13-stable and 14-stable on my hardware, however it is likely that the same problem will occur on those branches, once they are released. So should we guard against all those versions and keep lto enabled on the still working branches, or simply disable LTO on armv7 overall and leave it like this until someone tests again on llvm18 once landed ?
Created attachment 248118 [details] no lto on armv7 and llvm17+
Created attachment 248130 [details] no lto on armv7 and llvm17+ I had the __FreeBSD_version off by one in the previous patch.
Created attachment 248139 [details] no lto on armv7 and llvm17+ patch refreshed to cleanly apply
It *might* be better to use something like this: USES= compiler:features .if ${CHOSEN_COMPILER_TYPE} == "clang" && ${COMPILER_VERSION} == 17 OPTIONS_EXCLUDE_armv7= LTO .endif Since it would avoid it for people using GCC or a different version of clang ... Thoughts? And I hope the bug in clang17 is fixed at some point and this can be removed
(In reply to Brad Davis from comment #16) Such approach seems more correct, indeed. However it seems to me that bsd.port.pre.mk must come after bsd.options.mk and therefore one can't rely on the options processing to disable LTO anymore, which make that approach a bit more convoluted. Oh well... I came up with the following patch, it works for me as well :) Though there might still be a nicer way ? Either way, it would be nice that it gets fixed somehow before py311 becomes the default for all the people relying on pre-built armv7 packages as without python there will be a lot less of them. Thank you.
Created attachment 248141 [details] no lto on armv7 and llvm17+ New tested and validated patch following Brad's suggested approach, and adding an upper bound to clang version to assert that this issue gets fixed in clang at some point.
Created attachment 248142 [details] no lto on armv7 and llvm17+ fix bad patch (forgot the guard arch)
(In reply to Benjamin Jacobs from comment #17) Good point, I forgot about that! I appreciate you finding a solution that is the best of both! Looks like builds for me with the latest patch.
Comment on attachment 248142 [details] no lto on armv7 and llvm17+ Looks good, can you git-format-patch(1) so you are attributed properly? Also maybe add a brief comment about the compile/link bug on armv7?
(In reply to Mikael Urankar from comment #9) Built on qemu but ran on real hardware.
Created attachment 248186 [details] no lto on armv7 and llvm17+ git format-patch and comment as requested
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=5b0b801228eba3d1dfc39b9b595b3a089e118dc1 commit 5b0b801228eba3d1dfc39b9b595b3a089e118dc1 Author: Benjamin Jacobs <freebsd@dev.thsi.be> AuthorDate: 2024-02-04 18:13:23 +0000 Commit: Charlie Li <vishwin@FreeBSD.org> CommitDate: 2024-02-04 19:30:27 +0000 lang/python311: Fix build on armv7 with LLVM 17 Reported by: brd PR: 276249 lang/python311/Makefile | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
Committed, with a matching <bsd.port.post.mk> at the end. Thanks!
Thanks Charlie!
A commit in branch 2024Q1 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=a42b94911f1a406fbc2e0efc46376c33e866e33b commit a42b94911f1a406fbc2e0efc46376c33e866e33b Author: Benjamin Jacobs <freebsd@dev.thsi.be> AuthorDate: 2024-02-04 18:13:23 +0000 Commit: Charlie Li <vishwin@FreeBSD.org> CommitDate: 2024-02-08 06:57:42 +0000 lang/python311: Fix build on armv7 with LLVM 17 Reported by: brd PR: 276249 (cherry picked from commit 5b0b801228eba3d1dfc39b9b595b3a089e118dc1) lang/python311/Makefile | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)