-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Install utility does not compile on Windows #1174
Comments
How are you trying to build? At the moment, the proper way to build on Windows is I'm not sure how modes should work on Windows honestly, as Windows permissions are different from Unix permissions. I suppose if you want |
I built it with that and it totally worked! Thanks! Would it be possible to add those instructions to README? I think it would be useful for people trying to use the project on Windows. On the bigger picture, Windows does have some vaguely analogous features. It looks like the I don't see any of the authorization functions in the winapi crate, so they might not be available yet. It looks like |
No problem. :) I actually didn't realize they weren't in the README, so I'll add them later (unless someone does it before me). I'm thinking that we'll just make them no-ops (or issue an error at runtime or something) unless we can figure out a clear mapping between the Unix-style permissions and Windows ones. We might want to take a look at how existing ports of the GNU coreutils to Windows handle this issue (by seeing what Windows permissions are changed after running things like |
This looks like a really tricky issue. Cygwin (the only coreutils port I've ever used) has a bunch of documentation on how they implemented their system. They spend a lot of time on windows user-uid mapping, but then under the "File permissions" heading they go through some of the complexities with chmod. It looks like they do make a best-effort attempt at making it all work, but I'm not sure if it makes sense to put that level of effort into implementing it here. Doing Cygwin-style shimming for any more of glibc on Windows would be a major project. I think it makes sense for it to be a no-op with a runtime error, at least for now. The same probably applies to some of the other crates that don't build on Windows (chmod, chown, chroot, groups?, hostid?). |
Yeah, I'm inclined to just make them no-ops at the moment. Some of the ones that don't build on Windows right now actually can be relatively easily made to support Windows but need someone to look through the Windows docs and write some platform-specific code. Of course, in some cases, the code needed to properly support Windows is non-trivial, despite seemingly like the necessary code should be relatively simple (e.g. look at this). |
The
install
utility fails to build on Windows (nightly-x86_64-pc-windows-gnu 2018-03-27).It looks like the error is because install/mode.rs doesn't use
uucore::mode
on Windows, but doesn't have an alternate implementation ofparse
for Windows to use.coreutils/src/install/mode.rs
Lines 5 to 18 in 87d317e
Does it make sense to break up
parse
into Windows and non-Windows variants the same waychmod
is broken up? Or maybe something has to change at the caller to make sure Windows code doesn't rely onparse
?The text was updated successfully, but these errors were encountered: