On Montag, 31. Januar 2022 23:26:46 CET Will Cohen wrote:
> Upon further review, it looks like since 10.12 there's actually a
> (not-heavily-documented) function that wraps this syscall and avoids the
> need to call the private syscall directly:
> https://opensource.apple.com/source/libpthread/libpthread-218.51.1/src/pthre
> ad_cwd.c.auto.html. Chromium uses it too (
> https://chromium.googlesource.com/chromium/src/+/lkgr/base/process/launch_ma
> c.cc#110) -- given that we're not looking for pre-10.12 compatibility, I'm a
> little less worried about the workaround breaking in the future if this
> wrapper gets used instead.
>
> Would it work to change to pthread_fchdir_np, remove all the syscall
> discussion in the comment, and add a meson check for pthread_fchdir_np as a
> prereq for virtfs on darwin?
Using pthread_fchdir_np() looks like a better solution, yes. It still seems to
be a private macOS API though. I can't find the function in any of Apple's
publicly released header file, and Chromium therefore declares the function by
itself (directly in launch_mac.cc):
extern "C" {
// Changes the current thread's directory to a path or directory file
// descriptor. libpthread only exposes a syscall wrapper starting in
// macOS 10.12, but the system call dates back to macOS 10.5. On older OSes,
// the syscall is issued directly.
int pthread_chdir_np(const char* dir) API_AVAILABLE(macosx(10.12));
int pthread_fchdir_np(int fd) API_AVAILABLE(macosx(10.12));
...
} // extern "C"
But if you are guarding this with a meson check then sure, no objections from
my side at least.
Adding Peter on CC just in case.
Best regards,
Christian Schoenebeck
