Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/sys/unix: ___getdirentries64 results in app store rejections #34400

Closed
zx2c4 opened this issue Sep 19, 2019 · 5 comments
Closed

x/sys/unix: ___getdirentries64 results in app store rejections #34400

zx2c4 opened this issue Sep 19, 2019 · 5 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@zx2c4
Copy link
Contributor

zx2c4 commented Sep 19, 2019

While the fix for #30933 addressed go/syscall, it didn't address x/sys/unix. Meanwhile the fix for #28984 addressed go/syscall and x/sys/unix, but that's just for arm (iOS).

In order to fully fix things, the x/sys/unix patch for iOS needs to apply to macOS too.

CC @eliasnaur

@gopherbot gopherbot added this to the Unreleased milestone Sep 19, 2019
@eliasnaur
Copy link
Contributor

Thanks for making sure this is not forgotten. I don't intend to work on this, but perhaps a fix can be pieced together from https://golang.org/cl/168479 and https://golang.org/cl/170892.

@gopherbot
Copy link

Change https://golang.org/cl/196478 mentions this issue: unix: avoid __getdirentries64 on darwin

@tklauser
Copy link
Member

...but perhaps a fix can be pieced together from https://golang.org/cl/168479 and https://golang.org/cl/170892.

I sent https://golang.org/cl/196478 doing that.

This works fine for Go 1.12, but unfortunately x/sys/unix also provides compatibility funcs for Go 1.11 where we still use raw syscalls instead of libSystem. I'm not sure how to solve this there. Any ideas? Do we still need to support Go 1.11 in x/sys/unix now that Go 1.13 is out?

/cc @bradfitz @ianlancetaylor @randall77

@bradfitz
Copy link
Contributor

Arguably Go 1.11 users can use modules already, so we don't really have to keep GOPATH mode working for them (they can pin an older version). I'm okay removing that support if that's much easier.

But if a bit of build tag work keeps Go 1.11 around for another release, that'd be ideal.

@tklauser
Copy link
Member

But if a bit of build tag work keeps Go 1.11 around for another release, that'd be ideal.

Thanks, I think I found a way do solve it using some additional Go version specific files and build tags, ptal at https://golang.org/cl/196478

@toothrot toothrot added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Sep 19, 2019
@golang golang locked and limited conversation to collaborators Oct 1, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

6 participants