-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Omnibus to get a clean OpenBSD build. #3003
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
Conversation
x86_64 is spelled "amd64" on this platform. Return "amd64", for consistency with Swift and other projects.
See e.g., LibcOverlayShims.h in Swift.
Don't try to unconditionally use it. I don't know if this has any untoward side effects but running tests seems to be generally OK.
@swift-ci test |
} | ||
} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would this have issues if the executable was specified using a relative path ,eg ../some_executable
? It would fail the first check but not necessarily be in the PATH
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that would not work if the realpath call failed and we fell back to argv[0]. We can call realpath a second time to ensure we get an absolute path. Added missing free calls as well.
9e4d00c
to
f6ec0a0
Compare
@swift-ci test |
f6ec0a0
to
51fccb9
Compare
Addressed the relative path issue, also amended a small cmake change that I missed earlier. |
@swift-ci test |
@swift-ci test linux |
while ((p = strsep(&paths, ":")) != NULL) { | ||
char pp[PATH_MAX]; | ||
snprintf(pp, PATH_MAX, "%s/%s", p, argv0); | ||
char *res = realpath(pp, NULL); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if snprintf
returns >= PATH_MAX
the path in pp
will be truncated and thus invalid.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fine, if the path to the binary is going to be too long, we will truncate and when we try and see if the truncated file exists, we'll get an error and we'll fall out of this case. Although, did you have an alternative suggestion in mind?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The truncated name could still be another valid executable on the filesystem, I would suggest just treating the truncation the same way the realpath
failure is treated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point! Fixed.
free(res); | ||
} | ||
free(argv0); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you just tidy up the formatting in this if
block so its all consistent at 4 space indent, thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops -- sorry about that. Fixed.
51fccb9
to
39816ef
Compare
There is no native mechanism to get the running process path on OpenBSD. Currently, the shell needs to cooperate and fill in the path. This works, but not all shells set the `_` environment variable. We however are able to get `argv[0]` via sysctl on this platform. Instead of just trying `_` and then giving up otherwise, first try getting `argv[0]`. If that appears to be an absolute path, then we can likely assume that this is what we need; otherwise, search PATH. On other BSD platforms, this sysctl may need to be modified or an alternative mechanism supplied to get `argv[0]`, so we still fallback on `getenv("_")`.
These may be better handled by some other mechanism, but for now, make these changes to get a clean compile: * getnameinfo on BSD takes a `size_t` for the host name, not a `socklen_t`. * PTHREAD_MUTEX_RECURSIVE is part of an enum on OpenBSD, so requires `.rawValue`. * Like on Android, SOCK_STREAM and SOCK_DGRAM are not enums. INADDR_LOOPBACK is a complex macro, so requires defining the flattened the value (this is of course brittle, but is the best option for now).
There is libexecinfo as a 3rd-party package, but don't expect it be available for now. This requires removing the -fexeceptions flag on this platform also. While we are doing this, introduce the necessary boilerplate to mark tests as expected failures.
OpenBSD doesn't support these particular errno symbols. Exclude them for this platform.
The mac OS implementation is close to what is required for OpenBSD but requires tweaking. Instead of trying to unify the two implementations with #if branches, just riff off the mac OS implementation and create a new platform specific implementation.
Add the relevant routines for getting and setting thread name in CFPlatform. While we are doing this, change an #if branch in CFStream to set thread name to using the actual routines declared in CFPlatform to do this.
39816ef
to
1f0a55f
Compare
@swift-ci test |
This pr includes a few changes -- not including runloop changes which will be in a different pr -- to get a clean Foundation build on OpenBSD. Both this pr and the runloop changes are required for Foundation to build properly, work, and pass tests on this platform.
Please feel free to request any or all to be split into multiple prs.
Of note:
FileManager+POSIX