-
Notifications
You must be signed in to change notification settings - Fork 10
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
Updated library isn't always correctly reloaded #1
Comments
Hi @t-mw, thanks for the issue. I ran into this doing game development a few months ago and eventually concluded that this regressed for me going from Rust 1.19.0 to 1.20.0, but that the new behavior is the best that can guaranteed by POSIX, so we were just getting lucky earlier. As a first workaround, perhaps see if an older version of Rust behaves like you want? If you want to properly fix it, see the Rust issue rust-lang/rust#44365 for some discussion of their workaround. If you want to contribute, trying to adapt the suggested |
I believe there might also be some file-locking issues with libraries on Windows that I'm not dealing with, so the fix that builds to a random/hashed/counter library name would also be a great solution to deal with that. |
Hi, thanks for the links - I'll have a read through the discussion. Confusingly, I'm able to get |
It looks like updating the library name fixes the issue for me. To automate it, I thought that ideally the build script would generate the library name, but it seems that In the end I went with t-mw@4f7be34, which is very hacky in that it relies on modifying the cargo manifest, but otherwise it should be set and forget. Without the build script the library should revert to the old behavior of using a fixed name. |
The build script has the disadvantage that it creates a new version of the library for each change, which for whatever reason is slower than compiling to the same target. This shell script works with the changes in the commit above on OS X, but doesn't need the build script changes and avoids compiling to new targets. |
If I understand correctly, that will copy the library to another path after compiling, then fix it up so it gets loaded. Is Do you know what an alternative to |
That's right - there's a path embedded in the dylib as The equivalent on Linux might be |
I tried out Linux (specifically Arch), and there it's enough to just copy the library with a new filename without patching it. So this script in combination with t-mw@4f7be34 works. Looks like mac still needs the patching though even with the latest Rust. |
Thanks for sharing this library.
I'm not sure if this is a bug in
live-reloading-rs
,rust_libloading
or OS X, but after triggering a live reload in macOS High Sierra (10.13.3) the old version of the library continues to be used.For example, after updating the demo application to use increments of
5
instead of2
and recompiling withcargo build --lib
, the console output looks like this:The same process on OS X El Capitan (10.11.6) produces the correct output.
Just putting this out there in case other people have the same issue.
The text was updated successfully, but these errors were encountered: