-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: Definition for O_PATH missing for most FreeBSD architectures #54355
Comments
I think adding O_PATH definition was a bit premature, given that the minimum supported FreeBSD version in go1.20 is 12.3, which lacks O_PATH support. |
cc @golang/freebsd |
As far as I can tell, attempting to use the O_PATH flag on 12.3 will just ignore it and open the directory as a file which probably isn't ideal. In my case, I only plan to use thie in FreeBSD 13.1 or later but perhaps pubishing the symbol in x/sys/unix isn't ideal if 12.x is a supported release. The value for O_PATH does not conflict with any other flags supported in 12.x. My workaround is to define the O_PATH constant in the application code which is a bit of a mess but otherwise should work. |
My concern is that writing/testing application on 13.1 and then using it on 12.3 might create a false assumption that it implements something that in fact is not supported by the host OS. |
I'm with agreement with @dmgk here, the zerrors_freebsd_riscv64.go should have been generated under a 12.3 Jail. |
Makes sense - thanks for the added context. When my work-in-progress (podman on FreeBSD) makes it to the FreeBSD ports/package tree, I'll make sure its only built for 13.1 or later. |
@paulzhol -- all of the 12.x releases will probably be EOL'd December 2023. would it be reasonable to include its definition at that time and close this issue? |
That seems reasonable. I guess this would change all the references to stable/12 in mkall.sh to stable/13 which would pick up any other additions to the ABI post 12.x |
FreeBSD 12.4 reaches its EOL date on 31st December. Hopefully, switching the reference branch to stable/13 in the New Year will also pick up the constants for netlink which was merged into stable/13 and is present in FreeBSD 13.2 and later. |
As I am trying to get FreeBSD netlink into go (see go-nuts list about this): when is the move to FreeBSD 13 as reference branch planned? And is there anything to help? |
I think it just needs someone to submit a pull request. FreeBSD-12 reached EOL at the end of 2023 and the current oldest supported version is 13.3 so the go reference branch could reasonably move to 13.3 (which should have working netlink) |
I will see what I can do, i.e., I'm at to change it to 13.3.
Am 06.09.24 um 17:04 schrieb Doug Rabson:
… I think it just needs someone to submit a pull request. FreeBSD-12
reached EOL at the end of 2023 and the current oldest supported version
is 13.3 so the go reference branch could reasonably move to 13.3 (which
should have working netlink)
—
Reply to this email directly, view it on GitHub <https://github.com/
golang/go#54355#issuecomment-2334259739>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/
ACGZSZXPX64XP27YY35YGDLZVHABBAVCNFSM6AAAAABNYYDEH2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZUGI2TSNZTHE>.
You are receiving this because you commented.Message ID: <golang/go/
***@***.***>
|
Change https://go.dev/cl/610836 mentions this issue: |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
import "golang.org/x/sys/unix" and try to use unix.O_PATH on FreeBSD 13.1 or later
What did you expect to see?
The program should compile
What did you see instead?
the program does not compile
Notes
This symbol has been present in FreeBSD system headers since 13.1-RELEASE. The generated go code in x/sys/unix contains a definition for riscv in zerrors_freebsd_riscv64.go but the constant is missing for all other architectures. This symbol is not arch-dependent and should have the same value on all supported architectures.
The text was updated successfully, but these errors were encountered: