murarth/rusti

rusti: error while loading shared libraries: librustc_driver-c8005792.so: cannot open shared object file: No such file or directory

Closed this issue · 8 comments

djanderson commented

Following the README directions verbatim:

  • rustup install nightly-2016-08-01
  • rustup run nightly-2016-08-01 cargo install --git https://github.com/murarth/rusti
  • rusti
$ rustup --version
rustup 0.6.3 (a0e2132 2016-08-28)
$ rustc --version
rustc 1.11.0 (9b21dcd6a 2016-08-15)
$ cargo --version
cargo 0.12.0-nightly (6b98d1f 2016-07-04)
$ rusti --version
rusti: error while loading shared libraries: librustc_driver-c8005792.so: cannot open shared object file: No such file or directory
djanderson commented

Further:

I obviously tried sudo ldconfig

$ sudo find / -type f -iname librustc_driver-c8005792.so
find: ‘/run/user/1000/gvfs’: Permission denied
/home/dja/.multirust/toolchains/nightly-2016-08-01-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_driver-c8005792.so
/home/dja/.multirust/toolchains/nightly-2016-08-01-x86_64-unknown-linux-gnu/lib/librustc_driver-c8005792.so
murarth commented

You have to run rusti using rustup, too.

rustup run nightly-2016-08-01 ~/.cargo/bin/rusti
  • 👍1
djanderson commented

Huh, okay. I had tried rustup run nightly-2016-08-01 rusti and had gotten error: command failed: 'rusti' info: caused by: No such file or directory (os error 2) but hadn't thought to put in the fully qualified path because its in my PATH.

Now however, I'm getting another error:

$ RUST_BACKTRACE=1 rustup run nightly-2016-08-01 ~/.cargo/bin/rusti
thread 'main' panicked at 'assertion failed: !res.is_null()', .cargo/registry/src/github.com-1ecc6299db9ec823/linefeed-0.1.2/src/unix/terminfo.rs:210
stack backtrace:
   1:     0x7fa2f2ac28cf - std::sys::backtrace::tracing::imp::write::h29f5fdb9fc0a7395
   2:     0x7fa2f2ad47fb - std::panicking::default_hook::_{{closure}}::h2cc84f0378700526
   3:     0x7fa2f2ad2f75 - std::panicking::default_hook::hbbe7fa36a995aca0
   4:     0x7fa2f2ad357e - std::panicking::rust_panic_with_hook::h105c3d42fcd2fb5e
   5:     0x561d2981507f - std::panicking::begin_panic::h5c54e97e5cda1cc4
   6:     0x561d29826c12 - linefeed::sys::terminfo::get_str::h64786811a7590325
   7:     0x561d29820d52 - _<linefeed..sys..terminal..Terminal as linefeed..terminal..Terminal>::new::he6ab41f08059c182
   8:     0x561d2979537a - rusti::input::InputReader::new::h0922dbb481c8375d
   9:     0x561d2979fc40 - rusti::repl::Repl::run::h89902dc52bec47c6
  10:     0x561d297a9d99 - rusti::run::h43d5f2289cbda40f
  11:     0x561d29702825 - rusti::main::hc882e1fb571d612f
  12:     0x7fa2f2ad31f8 - std::panicking::try::call::h5df3ac2979db3c90
  13:     0x7fa2f2ae2fb6 - __rust_maybe_catch_panic
  14:     0x7fa2f2ad22fe - std::rt::lang_start::hfe9ab243c60ffb9b
  15:     0x7fa2f1abf82f - __libc_start_main
  16:     0x561d29702718 - _start
  17:                0x0 - <unknown>
murarth commented

What terminal software are you using?

djanderson commented

emacs shell. Other languages' interpreters I've used recently behave correctly (python, ipython, scala)

murarth commented

Apparently, Emacs does not provide a terminfo entry and expects programs to treat it as a "dumb" terminal. rusti's new readline replacement, linefeed, does not currently support "dumb" terminals (out of laziness).

I've filed an issue for this on linefeed (murarth/linefeed#5) and so I'm now closing this issue.

murarth commented

@djanderson: Until linefeed has better support for dumb terminals, I have at least pushed a change that will cause an error in this case instead of a panic. That way, rusti can (and now does; checkout the latest commit) catch the error and fallback to just plain reading from stdin. It's not optimal, but it's a little better than a panic.

djanderson commented

@murarth, just tried it out... was usable. Thanks!