[Toybox] macOS realpath test failures

enh enh at google.com
Wed Dec 14 10:48:49 PST 2022


On Tue, Dec 13, 2022 at 7:52 PM Rob Landley <rob at landley.net> wrote:

> Thanks to Zach for getting me sh access to a mac, mac is passing its tests
> again.
>

nice! thanks both!

(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...)


> It had two problems:
>
> A) The mac test for "does chmod +s work as a normal user" in chmod.test
> wasn't
> converted to the new format properly (5f7faac45363 missed one and I didn't
> notice because it only mattered on mac), which is weird because you'd
> think mac
> would hit that failure FIRST on github and android? (Weird. I just did
> homebrew,
> gmake macos_defconfig, gmake tests...)
>

(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.)


> II) Mac hasn't got O_PATH and portability.h was doing an #ifdef check and
> defining it, because it was only added to the kernel in 2011 (commit
> 1abf0c718f15a) and the 7 year horizon for that was still relevant
> pre-pandemic.
>
> Mac still hasn't got O_PATH but the numeric value Linux uses was already
> allocated in mac for O_SYMLINK "allow open of a symlink" (which Linux
> hasn't
> got), hence the weird behavior.
>
> Not a kernel bug, a portability.h bug.
>

ah, that makes more sense!


> Rob
>
> P.S. Ironically, pulling the second mac fix into my main work tree hit a
> conflict because I was doing a pass tracking down the expiration dates of
> symbols in there, recording the kernel commit that added them. Which
> rolled to a
> stop because AT_FDCWD was added in 2006 and RLIMIT_RTTIME wsa 2008 and
> they've
> got to still be there because because a specific build environment needed
> them,
> but which one? Having updated Mac, BSD, and NDK build environments to
> regression
> test against hopefully lets me resume that cleanup...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20221214/5955973f/attachment.htm>


More information about the Toybox mailing list