Building for darwin on nix fails #516
Comments
|
Awesome, thanks for this! So, we do indeed use |
|
I have no idea about darwin and little idea about nix, but I am happy to test fixes. |
|
OK, so I think there is a potential fix for this, but it requires some thought before committing to it. @alexcrichton @sunfishcode I'd very much appreciate your opinion on this. The potential fix, in principle, would require the same mechanism as the one used in @alexcrichton's filetime crate for checking whether a symbol exists at runtime: static ADDR: AtomicUsize = AtomicUsize::new(0);
let func: Option<unsafe extern "C" fn(...)> = unsafe {
fetch(&ADDR, b"utimensat\0").map(|sym| mem::transmute(sym))
};
if let Some(func) = func {
// Success! "utimensat" symbol was found on our host
// Call utimensat(...)
func(fd, path, ...);
} else {
// Sad days, "utimensat" is not available on this host
}In case of the negative route, when let fd = unsafe { libc::openat(dirfd, path, libc::O_NOFOLLOW | libc::O_RDWR) };
unsafe { libc::futimes(fd, times.as_ptr()) };But this becomes somewhat messy, plus it adds up to two additional syscalls (one to get the file descriptor using Originally, I thought of extending filetime crate with this use case in mind, but I'm now I'm hesitant as it could potentially break the symmetry in implementation between Linux and BSD hosts. Anyhow, the question here is should we support hosts without |
|
I'm generally of the opinion that on recent (ish) versions of a platform is where a program should be the most optimized, and if a slower polyfill is required on older platforms that's better than not having the functionality at all. In that sense if the polyfill for older platforms requires some hoops and a few more syscalls I personally think that's ok. Also FWIW if this is on Linux I'd recommend using |
Makes sense! :-)
Yep, absolutely. I was going to basically steal much of the "meat" from your lib, |
|
That sounds like a good approach to me! |
|
What's done in filetime for How about writing some macro that would automatically generate the Idea: or I'm not sure if we can create convert |
|
@kubkon, were you able to make progress here? |
|
Hey @nomeata, apologies but I didn't have time to properly sit down to it yet. Having said that I've got some more time this week, so hopefully, I'll get most of it (if not all) done this week. The moment I get something working and reviewed, I shall let you know and kindly ask for your help in verifying that the changes are actually correct. |
kubkon
added
bug
This commit introduces a change to file time management for *nix based hosts in that it firstly tries to load `utimensat` symbol, and if it doesn't exist, then falls back to `utimes` instead. This change is borrowing very heavily from [filetime] crate, however, it introduces a couple of helpers and methods specific to WASI use case (or more generally, to a use case which requires modifying times of entities specified by a pair `(DirFD, RelativePath)` rather than the typical file time specification based only absolute path or raw file descriptor as is the case with [filetime] crate. The trick here is, that on kernels which do not have `utimensat` symbol, this implementation emulates this behaviour by a combination of `openat` and `utimes`. This commit also is meant to address bytecodealliance#516. [filetime]: https://github.com/alexcrichton/filetime
This commit introduces a change to file time management for *nix based hosts in that it firstly tries to load `utimensat` symbol, and if it doesn't exist, then falls back to `utimes` instead. This change is borrowing very heavily from [filetime] crate, however, it introduces a couple of helpers and methods specific to WASI use case (or more generally, to a use case which requires modifying times of entities specified by a pair `(DirFD, RelativePath)` rather than the typical file time specification based only absolute path or raw file descriptor as is the case with [filetime] crate. The trick here is, that on kernels which do not have `utimensat` symbol, this implementation emulates this behaviour by a combination of `openat` and `utimes`. This commit also is meant to address bytecodealliance#516. [filetime]: https://github.com/alexcrichton/filetime
This commit introduces a change to file time management for *nix based hosts in that it firstly tries to load `utimensat` symbol, and if it doesn't exist, then falls back to `utimes` instead. This change is borrowing very heavily from [filetime] crate, however, it introduces a couple of helpers and methods specific to WASI use case (or more generally, to a use case which requires modifying times of entities specified by a pair `(DirFD, RelativePath)` rather than the typical file time specification based only absolute path or raw file descriptor as is the case with [filetime] crate. The trick here is, that on kernels which do not have `utimensat` symbol, this implementation emulates this behaviour by a combination of `openat` and `utimes`. This commit also is meant to address bytecodealliance#516. [filetime]: https://github.com/alexcrichton/filetime
|
Hi @nomeata, could you do me a favour and try building |
This commit introduces a change to file time management for *nix based hosts in that it firstly tries to load `utimensat` symbol, and if it doesn't exist, then falls back to `utimes` instead. This change is borrowing very heavily from [filetime] crate, however, it introduces a couple of helpers and methods specific to WASI use case (or more generally, to a use case which requires modifying times of entities specified by a pair `(DirFD, RelativePath)` rather than the typical file time specification based only absolute path or raw file descriptor as is the case with [filetime] crate. The trick here is, that on kernels which do not have `utimensat` symbol, this implementation emulates this behaviour by a combination of `openat` and `utimes`. This commit also is meant to address bytecodealliance#516. [filetime]: https://github.com/alexcrichton/filetime
* Dynamically load utimensat if exists on the host This commit introduces a change to file time management for *nix based hosts in that it firstly tries to load `utimensat` symbol, and if it doesn't exist, then falls back to `utimes` instead. This change is borrowing very heavily from [filetime] crate, however, it introduces a couple of helpers and methods specific to WASI use case (or more generally, to a use case which requires modifying times of entities specified by a pair `(DirFD, RelativePath)` rather than the typical file time specification based only absolute path or raw file descriptor as is the case with [filetime] crate. The trick here is, that on kernels which do not have `utimensat` symbol, this implementation emulates this behaviour by a combination of `openat` and `utimes`. This commit also is meant to address #516. [filetime]: https://github.com/alexcrichton/filetime * Fix symlink NOFOLLOW flag setting * Add docs and specify UTIME_NOW/OMIT on Linux Previously, we relied on [libc] crate for `UTIME_NOW` and `UTIME_OMIT` constants on Linux. However, following the convention assumed in [filetime] crate, this is now changed to directly specified by us in our crate. [libc]: https://github.com/rust-lang/libc [filetime]: https://github.com/alexcrichton/filetime * Refactor UTIME_NOW/OMIT for BSD * Address final discussion points
With this bump, we pull in support for building on darwin, i.e. bytecodealliance/wasmtime#516
With this bump, we pull in support for building on darwin, i.e. bytecodealliance/wasmtime#516 (cherry picked from commit 3ce8c48)
Trying to build on nix for darwin, (see NixOS/nixpkgs#71316), I hit the following problem:
I read somewhere that on nix, certain symbols are removed from
libsystemthat are not available on all versions of MacOS. (See first two messages on https://logs.nix.samueldr.com/nix-darwin/2019-07-26)The text was updated successfully, but these errors were encountered: