Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Mono musl support #76500
Mono musl support #76500
Changes from all commits
53fca63
9b88228
579a65c
17a33f2
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
@ayakael
Why FICLONE casted to int? Second argument of ioctl function is unsigned long and not int.
This caused ppc64le build error. Can you please revert this change?
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.
This was a proposal by @am11, as build failed without setting
Wno-sign-conversion
. See: #76500 (comment).Here is the exact error:
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 you change last argument to
unsigned long
here:runtime/src/native/libs/System.Native/pal_io.c
Line 76 in cbc8695
(int)FICLONE
cast, does it fix bothlinux-ppc64le
andlinux-musl-ppc64le
builds?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 would be incorrect - the
_IOW
macro usessizeof
its last argument as a component of the resulting value, so changing that size from 4 to 8 will result in an incorrect value ofFICLONE
.This issue seems to be caused by some difference in the definition of
ioctl
with musl. In glibc, we have this:Is this declared differently in musl?
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.
It is a ppc64le specific issue, where musl and glibc have different definitions. Rest of the platform matrix (including linux-musl-x64/arm64/arm etc..) is fine either way.
I see, so the current definition is also incorrect; should be
size_t
instead ofint
, right?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 only difference between ppc64le and other platforms is the numerical value of
FICLONE
here. On ppc64le, this value is0x80049409
while on other platforms it is0x40049409
due to a different definition of the_IOW
macro. This means on other platforms the value is the same interpreted asint
andunsigned long
, so there's no compiler warning. On ppc64le, the value is negative interpreted asint
and positive interpreted asunsigned long
, that's why we get the warning. The type mismatch itself is currently present on all platforms.No. We must use
sizeof (int)
, i.e. 4, here; this flows into the construction of that value above.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.
Indeed this seems to be problem. In the musl headers I see instead:
I guess as long as the two headers differ, there's probably no way to fix the source to work with both libcs, except for using some #ifdef ...