Currently, the build system dev-util/b2-4.9.3, notably used by Boost, crashes on Apple M1 w/ macOS with a Segmentation Fault. This prevents one from using the tool, and also making building Boost impossible. It's also notable since it contains the keyword "~x64-macos", so it should receive first-class macOS support. /Users/ec2-user/gentoo/var/tmp/portage/dev-libs/boost-1.81.0-r1/temp/environment: line 1465: 93936 Segmentation fault: 11 b2 "${b2_opts[@]}" ec2-user@ip-10-0-4-85 ~ $ b2 Segmentation fault: 11 This is a known upstream problem [1], and it hasn been determined that the problem was caused by passing an incompatibility data type into variadic function filter_create_ext(). I'll soon submit a patch to fix this problem. [1] https://github.com/bfgroup/b2/issues/152
(In reply to Tom Li from comment #0) > Currently, the build system dev-util/b2-4.9.3, notably used by Boost, > crashes on Apple M1 w/ macOS with a Segmentation Fault. This prevents one > from using the tool, and also making building Boost impossible. It's also > notable since it contains the keyword "~x64-macos", so it should receive > first-class macOS support. Note that this is _not_ the arm64 keyword, but we use it as a hack right now: ``` $ grep -rsin x64-macos | grep -i arm64 prefix/darwin/macos/arch/arm64/make.defaults:5:ACCEPT_KEYWORDS="~x64-macos" # this is a hack whilst we don't have full system prefix/darwin/macos/arch/arm64/use.mask:5:-x64-macos prefix/darwin/macos/arch/arm64/use.force:5:x64-macos [...] ``` I think we should undo this, because clearly there's some fun porting issues wrt the apple arm64 ABI and things need to be retested. the x64-macos keyword is for amd64 macos. grobian?
x64 is AMD64 and x86_64
(In reply to Fabian Groffen from comment #2) > x64 is AMD64 and x86_64 and how is that related to macOS on M1, i.e., arm64?
Well, in the pure sense of AMD64 != ARM64, nothing, of course. But we have a culprit and patch now, right? https://github.com/bfgroup/b2/pull/214/files
The point being that keywords exist for a reason (to show if we tested something and it worked) so reusing the old keyword is proving problematic, so I'm asking if we can cut the cord and just use the new one without the hack in the profiles
(In reply to Fabian Groffen from comment #4) > Well, in the pure sense of AMD64 != ARM64, nothing, of course. > > But we have a culprit and patch now, right? > > https://github.com/bfgroup/b2/pull/214/files If you're going to keep merging keywords on a whim, I will fix it through QA.
(In reply to Sam James from comment #5) > The point being that keywords exist for a reason (to show if we tested > something and it worked) so reusing the old keyword is proving problematic, > so I'm asking if we can cut the cord and just use the new one without the > hack in the profiles Yes, that's a completely valid remark, and this should've never lasted longer than what was a brief test-period. In fact I don't think it shoul've been done in the first place, but I don't remember anymore why or what lead to this. The @system set should just receive ~arm64-macos keywords, the keyword was setup for this.
(In reply to David Seifert from comment #6) > If you're going to keep merging keywords on a whim, I will fix it through QA. I don't understand this, I'm not aware of constantly "merging keywords", or whatever that may mean. That said, if you feel QA needs to step in here, then that will be unfortunate, but the way it is.
(In reply to Fabian Groffen from comment #8) > (In reply to David Seifert from comment #6) > > If you're going to keep merging keywords on a whim, I will fix it through QA. > > I don't understand this, I'm not aware of constantly "merging keywords", or > whatever that may mean. That said, if you feel QA needs to step in here, > then that will be unfortunate, but the way it is. So what's the plan? Remove the ACCEPT_KEYWORDS="~x64-macos" from arm64 prefix and add ~arm64-macos properly? Timeline?
(In reply to David Seifert from comment #9) > So what's the plan? Remove the ACCEPT_KEYWORDS="~x64-macos" from arm64 > prefix and add ~arm64-macos properly? Timeline? That is the plan indeed. I think if we want to execute this fast, we can do it today, and bother about the missing keywords later, when I've been able to do a rebuild to confirm all works.
(In reply to Fabian Groffen from comment #10) > (In reply to David Seifert from comment #9) > > So what's the plan? Remove the ACCEPT_KEYWORDS="~x64-macos" from arm64 > > prefix and add ~arm64-macos properly? Timeline? > > That is the plan indeed. I think if we want to execute this fast, we can do > it today, and bother about the missing keywords later, when I've been able > to do a rebuild to confirm all works. Thank you, that sounds like a plan.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=806ed912c90eece112c9225c5308f0f837ef0b5a commit 806ed912c90eece112c9225c5308f0f837ef0b5a Author: Yifeng Li <tomli@tomli.me> AuthorDate: 2023-02-20 10:54:29 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-02-20 13:48:17 +0000 dev-util/b2: fix crash on Apple M1 due to undefined behavior. Currently, the build system dev-util/b2-4.9.3, notably used by Boost, crashes on Apple M1 w/ macOS with a Segmentation Fault. This prevents one from using the tool, and also making building Boost impossible. It's also notable since it contains the keyword "~x64-macos", so it should receive first-class macOS support. It has been determined that when the NULL-terminated variadic function call_rule() is invoked, the value 0 is passed as the last argument to act as a terminator. However, this is an integer value, which is incompatible with the pointer data type expected by call_rule(). This is undefined behavior in C, correct operation is not guaranteed. In fact, it causes b2 to crash on Apple M1 when GCC is used - the loop is not terminated when it should, instead, it keeps running, creating the following error: lol_add failed due to reached limit of 19 elements In some cases, it can even corrupt the internal state of the program, creating an infinite loop. This commit fixes the problem by explicitly casting the value 0 to the correct pointer type (OBJECT *). Since the existence of the bug doesn't prevent one from installing the package, it can lurk inside the system and remain undetected, furthermore, it's technically a C programming bug, other platforms could've been affected as well in theory. Thus, we also bump the package version. Closes: https://bugs.gentoo.org/895524 Signed-off-by: Yifeng Li <tomli@tomli.me> Closes: https://github.com/gentoo/gentoo/pull/29681 Signed-off-by: Sam James <sam@gentoo.org> dev-util/b2/b2-4.9.3-r1.ebuild | 67 ++++++++++++++++++++++ ...x-apple-m1-crash-by-explicit-pointer-cast.patch | 55 ++++++++++++++++++ 2 files changed, 122 insertions(+)
(In reply to Fabian Groffen from comment #10) > (In reply to David Seifert from comment #9) > > So what's the plan? Remove the ACCEPT_KEYWORDS="~x64-macos" from arm64 > > prefix and add ~arm64-macos properly? Timeline? > > That is the plan indeed. I think if we want to execute this fast, we can do > it today, and bother about the missing keywords later, when I've been able > to do a rebuild to confirm all works. Thanks, that sounds good to me!
