Try mustang on real-world programs!
#22
Labels
good first issue
Good for newcomers
Comments
|
I tried to run an async web app using tokio, it failed in tokio initialization because What the error looks likeWhen using the Also, |
|
I found an application I wrote that works with mustang: https://github.com/jplatte/i3-workspace-scroll It's < 50 LOC but it uses command line arguments and some IPC through a socket file. One thing I was curious about was file sizes. Here's a comparison:
The sizes of the |
|
Thanks for trying it out! I believe you're the first person to have tried anything with async 😄 . Fortunately, I expect Concerning code size, mustang currently forces its entire libc to be statically linked in, in order to prevent the linker from satisfying any symbol references with the platform libc. I'm hoping to find a better approach there. |
|
With #45, mustang no longer forces its entire libc to be statically linked in, and file sizes are much smaller. For example, unstripped release hello world on x86_64 went from 1.8M to 640K. |
|
Using latest ( |
|
Thanks to @nivkner implementing When ripgrep runs on a single file, instead of on a directory, it uses When ripgrip runs on directories, it appears to run successfully, but it also prints out several messages about unimplemented This is #40. |
|
I tried running bat with mustang. Following the README, I installed
indexmap = { version = "*", features = ["std"] }I also ran into an an unrelated regression on Nightly which was easy enough to work around. After the above modifications, it successfully passed the compilation step, but failed during linking. The traceback is ~1200 lines long; I'm happy to post it if it's helpful, but it looks generally like this: It seems like I must have configured something incorrectly, but I can't tell from the README. |
|
Cool, thanks for trying bat, that's a fun idea! It looks like you've configured everything correctly; the errors you're seeing there are bugs in mustang. Specifically, mustang so far has focused on running Rust code, and bat uses libgit2 written in C. Mustang's libc support so far only covers things used by Rust, so it doesn't yet have all the things that are common to use in C programs. #69 is a PR to add a note about this to the README.md. A possible workaround might be to disable the |
|
Neat! That makes sense, I see That narrowed the errors down to just this one: That's in the standard library, so I went ahead and manually modified that #[cfg(all(target_os = "linux", target_env = "gnu"))]
pub fn glibc_version() -> Option<(usize, usize)> {
+ None
- extern "C" {
- fn gnu_get_libc_version() -> *const libc::c_char;
- }
- let version_cstr = unsafe { CStr::from_ptr(gnu_get_libc_version()) };
- if let Ok(version_str) = version_cstr.to_str() {
- parse_glibc_version(version_str)
- } else {
- None
- }
}After a clean rebuild, it successfully compiled! It panics when running, which I guess is the point of this issue 😄 So that's coming from https://github.com/eminence/terminal-size/blob/master/src/unix.rs#L31: ioctl(fd, TIOCGWINSZ.into(), &mut winsize)On the other hand, if I prevent that code from getting run with a small patch: diff --git a/src/bin/bat/app.rs b/src/bin/bat/app.rs
index 842eec6..b60276f 100644
--- a/src/bin/bat/app.rs
+++ b/src/bin/bat/app.rs
@@ -179,7 +179,7 @@ impl App {
_ => unreachable!("other values for --color are not allowed"),
},
paging_mode,
- term_width: maybe_term_width.unwrap_or(Term::stdout().size().1 as usize),
+ term_width: maybe_term_width.unwrap_or_else(|| Term::stdout().size().1 as usize),
loop_through: !(self.interactive_output
|| self.matches.value_of("color") == Some("always")
|| self.matches.value_of("decorations") == Some("always")...and pass the It's very slow though, and I still can't get it to link in Release mode. I get ~250 lines of undefined reference errors, which appear to all be originating from |
|
Cool! #68 adds I don't know what's going on with those release mode link errors yet though. Could you post the full log? You can use |
Closed
|
Those two PRs work great! I was able to remove the workarounds for them. Full log from
|
|
Could you try commenting out the |
|
That did the trick! |
|
I also tried Linker errors:
= note: /usr/bin/ld: /tmp/cargo-watch/target/x86_64-mustang-linux-gnu/debug/deps/libpolling-31a2aec96d0b6c5b.rlib(polling-31a2aec96d0b6c5b.polling.a8c404e5-cgu.0.rcgu.o): in function `polling::epoll::Poller::new::{{closure}}':
/home/antonok/.config/cargo/registry/src/github.com-1ecc6299db9ec823/polling-2.2.0/src/epoll.rs:38: undefined reference to `epoll_create'
/usr/bin/ld: /tmp/cargo-watch/target/x86_64-mustang-linux-gnu/debug/deps/libcommand_group-63ab48226defceab.rlib(command_group-63ab48226defceab.command_group.9645ae60-cgu.12.rcgu.o): in function `nix::unistd::setsid':
/home/antonok/.config/cargo/registry/src/github.com-1ecc6299db9ec823/nix-0.22.0/src/unistd.rs:290: undefined reference to `setsid'
/usr/bin/ld: /tmp/cargo-watch/target/x86_64-mustang-linux-gnu/debug/deps/libcommand_group-63ab48226defceab.rlib(command_group-63ab48226defceab.command_group.9645ae60-cgu.14.rcgu.o): in function `nix::sys::signal::killpg':
/home/antonok/.config/cargo/registry/src/github.com-1ecc6299db9ec823/nix-0.22.0/src/sys/signal.rs:775: undefined reference to `killpg'
/usr/bin/ld: /tmp/cargo-watch/target/x86_64-mustang-linux-gnu/debug/deps/libnix-31eb011f1835f430.rlib(nix-31eb011f1835f430.nix.d2ab827a-cgu.8.rcgu.o): in function `nix::sys::signal::SigSet::wait':
/home/antonok/.config/cargo/registry/src/github.com-1ecc6299db9ec823/nix-0.22.0/src/sys/signal.rs:491: undefined reference to `sigwait'
/usr/bin/ld: /tmp/cargo-watch/target/x86_64-mustang-linux-gnu/debug/deps/libnotify-3436058ff2beca65.rlib(notify-3436058ff2beca65.notify.c722c544-cgu.9.rcgu.o): in function `inotify::inotify::Inotify::add_watch':
/home/antonok/.config/cargo/registry/src/github.com-1ecc6299db9ec823/inotify-0.7.1/src/inotify.rs:194: undefined reference to `inotify_add_watch'
/usr/bin/ld: /tmp/cargo-watch/target/x86_64-mustang-linux-gnu/debug/deps/libinotify-894edffb26bc103f.rlib(inotify-894edffb26bc103f.inotify.946dde7f-cgu.3.rcgu.o): in function `inotify::inotify::Inotify::init':
/home/antonok/.config/cargo/registry/src/github.com-1ecc6299db9ec823/inotify-0.7.1/src/inotify.rs:104: undefined reference to `inotify_init'
/usr/bin/ld: /tmp/cargo-watch/target/x86_64-mustang-linux-gnu/debug/deps/libinotify-894edffb26bc103f.rlib(inotify-894edffb26bc103f.inotify.946dde7f-cgu.3.rcgu.o): in function `inotify::inotify::Inotify::rm_watch':
/home/antonok/.config/cargo/registry/src/github.com-1ecc6299db9ec823/inotify-0.7.1/src/inotify.rs:266: undefined reference to `inotify_rm_watch'
/usr/bin/ld: /tmp/cargo-watch/target/x86_64-mustang-linux-gnu/debug/deps/libmio-972309a7a773b3bb.rlib(mio-972309a7a773b3bb.mio.354b742d-cgu.5.rcgu.o): in function `mio::sys::unix::epoll::Selector::new':
/home/antonok/.config/cargo/registry/src/github.com-1ecc6299db9ec823/mio-0.6.23/src/sys/unix/epoll.rs:43: undefined reference to `epoll_create'
/usr/bin/ld: /tmp/cargo-watch/target/x86_64-mustang-linux-gnu/debug/deps/libmio-972309a7a773b3bb.rlib(mio-972309a7a773b3bb.mio.354b742d-cgu.7.rcgu.o): in function `mio::sys::unix::pipe':
/home/antonok/.config/cargo/registry/src/github.com-1ecc6299db9ec823/mio-0.6.23/src/sys/unix/mod.rs:71: undefined reference to `pipe'
/usr/bin/ld: /tmp/cargo-watch/target/x86_64-mustang-linux-gnu/debug/deps/libchrono-902c570d135cc492.rlib(chrono-902c570d135cc492.chrono.6d6b6782-cgu.8.rcgu.o): in function `chrono::sys::inner::time_to_local_tm':
/home/antonok/.config/cargo/registry/src/github.com-1ecc6299db9ec823/chrono-0.4.19/src/sys/unix.rs:84: undefined reference to `localtime_r'
collect2: error: ld returned 1 exit status
Compiling in release mode fails with
Seems like |
This was referenced Dec 8, 2021
Closed
Closed
Closed
Closed
|
@antonok-edm Thanks for the report! I've now filed several mustang bugs for the various undefined symbols there: #85, #86, #87, and #88.
The one symbol I didn't file a bug about yet is |
|
@sunfishcode I can't get
[package]
name = "testing"
version = "0.1.0"
edition = "2021"
[dependencies]
mustang = { path = "/path/to/latest/mustang" }
[profile.dev]
panic = "abort"
mustang::can_run_this!();
fn main() {} |
|
Ah, thanks. It looks like the |
|
Tried compiling one of my own apps with mustang and failed to link edit: I am unsure why I am getting the missing DSO error since I have a build.rs file linking to some libs, it's as if the build.rs is not executed when running |
Closed
|
I haven't seen DSO errors like that yet, so I don't have any guesses there. Would you be able to provide a link to the source code? Also, I filed #91 to track |
|
Sure, here you go. Thanks for working towards a libc-free Rust option =) |
|
Just tried uutils/coreutils (which, compiled with Mustang, would go a long way to a pure-Rust Linux userspace). Failed with a bunch of linker errors: Full linker outputThe missing symbols:
(Also, |
|
@eHammarstrom Thanks! I haven't investigated it in detail, but my guess of what's going on is that these lines in auto-display's build.rs: println!("cargo:rustc-link-lib=X11");
println!("cargo:rustc-link-lib=Xrandr");transitively pull in libc.so.6, which is then not happy about sharing a process with mustang. As a workaround, would it be possible to try statically linking with the X11 and Xrandr libraries? @Gaelan Cool, thanks for trying coreutils! Several of those functions are in the "top half" of libc, such as |
|
@carbotaniuman added |
|
@Gaelan My coreutils branch at https://github.com/sunfishcode/coreutils/ now passes all the tests in the default feature set under mustang, except |
|
Custom signal handlers are now implemented and coreutils' |
|
Unless I've missed something, everything reported here so far except lto and auto-display is now working: panic = "abort", bat (including git2 support), ripgrep, coreutils (including the "unix" feature set), cargo-watch, tokio, async-std. |
|
I'm interested in building a shared library with mustang. It then occurred to me that I had not seen any examples of using mustang to build a library, perhaps there is some fundamental issue there that I'm missing. (Like maybe the lack of a Also, obviously in the readme you've explicitly stated that mustang does not support dynamic linkage. Thats something I'd be interested in helping out with but would need mentoring. |
|
@estk Unfortunately, this activity is not among my own personal interests at this time, so I won't be able to be of much help. If you'd like though, you're welcome to file new issues in the issue tracker in this repo and describe what you're doing (ideally in as much detail as you can, eg: how are you expecting to load this library, is there another libc in the process, are there any threads anywhere, etc.) and what problems you're finding and ask questions, and perhaps there will be others interested in helping. |
|
@sunfishcode thank you so much for the super quick response on this! I've explained our situation a bit in the rust-lang issue but I'll file the relevant issues here and explain the situation in great (hopefully not painful) detail. 😄 Finally just an observation, I find it very surprising that the rustc team has not immediately co-opted this and run with it. (I was similarly surprised with the lukewarm reception of watt) I wonder if you can shed any light on the, from an outsider's perspective, lack of interest. |
|
I guess it's not much, but I was able to run It's about 23% slower, though, probably because of the allocator performance. I also tried |
|
@estk I expect it's just that for most users, Mustang doesn't have any practical advantages. It's less complete and less real-world tested than existing libc implementations. |
|
@lnicola Very cool! Could you say which unimplemented functions jemalloc needs? |
|
|
I can grind some of those out later today once I'm done with work. Not sure about the popcount one though, feels like we'd need another library off that... |
|
It's not very clear to me, but isn't I was surprised that |
|
I'm actually not sure why the popcount one is missing, compiler-builtins
appears to provide it...
…On Fri, Jun 9, 2023, 12:17 PM Laurențiu Nicola ***@***.***> wrote:
It's not very clear to me, but isn't count_ones available in libcore?
—
Reply to this email directly, view it on GitHub
<#22 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJ4ICPYZTGJDLSHDN64ROW3XKNLCJANCNFSM5EKNOFLA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
All the functions needed for jemalloc here are now implemented, except When I tried Mustang, I saw the undefined references to |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
Mustang is now complete enough to support the current directory, command-line arguments, environment variables,
std::fs,std::net,std::thread,std::time,std::alloc, and everything in the standard library that doesn't involve I/O too. It can now run some real-world programs! To try it:Identify a program to try. Ideally avoid the known limitations, however reports confirming the known limitations are still useful.
Follow the usage instructions in the README.
Post a comment here about whatever happens—success, failure of any kind, or something was unclear.
The text was updated successfully, but these errors were encountered: