<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 13, 2022 at 7:52 PM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks to Zach for getting me sh access to a mac, mac is passing its tests again.<br></blockquote><div><br></div><div>nice! thanks both!</div><div><br></div><div>(i _won't_ be updating AOSP this week though because i'm ooo the next two weeks, and don't want to leave any surprises for folks who will still be working. i'll catch up with all we've missed in the first week of january...)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It had two problems:<br>
<br>
A) The mac test for "does chmod +s work as a normal user" in chmod.test wasn't<br>
converted to the new format properly (5f7faac45363 missed one and I didn't<br>
notice because it only mattered on mac), which is weird because you'd think mac<br>
would hit that failure FIRST on github and android? (Weird. I just did homebrew,<br>
gmake macos_defconfig, gmake tests...)<br></blockquote><div><br></div><div>(i can't explain github, but Android doesn't have good infrastructure for running macOS tests, so there's _nothing_ in Android's CI for that. we _build_ for the mac, but we don't run the tests, which is why i pay so much attention to the github test results, and haven't synced AOSP since they went red.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
II) Mac hasn't got O_PATH and portability.h was doing an #ifdef check and<br>
defining it, because it was only added to the kernel in 2011 (commit<br>
1abf0c718f15a) and the 7 year horizon for that was still relevant pre-pandemic.<br>
<br>
Mac still hasn't got O_PATH but the numeric value Linux uses was already<br>
allocated in mac for O_SYMLINK "allow open of a symlink" (which Linux hasn't<br>
got), hence the weird behavior.<br>
<br>
Not a kernel bug, a portability.h bug.<br></blockquote><div><br></div><div>ah, that makes more sense! </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Rob<br>
<br>
P.S. Ironically, pulling the second mac fix into my main work tree hit a<br>
conflict because I was doing a pass tracking down the expiration dates of<br>
symbols in there, recording the kernel commit that added them. Which rolled to a<br>
stop because AT_FDCWD was added in 2006 and RLIMIT_RTTIME wsa 2008 and they've<br>
got to still be there because because a specific build environment needed them,<br>
but which one? Having updated Mac, BSD, and NDK build environments to regression<br>
test against hopefully lets me resume that cleanup...<br>
</blockquote></div></div>