Open location in Linux doesn't seem to work

[sophiajt]

When I do ctrl+l in Linux, I see this error at the terminal:

zenity: symbol lookup error: /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0: undefined symbol: hb_glib_get_unicode_funcs

[sophiajt]

I wonder if this is something weird in my setup, but worth reporting in case other people see this

[paulrouget]

Hmm, it's surprising. This is a harfbuzz symbol, right? No related to tinyfiledialog.

[sophiajt]

I'm trying to track it down to see what it is

[paulrouget]

Can you clone https://github.com/jdm/tinyfiledialogs-rs and run:

cargo run --example main

[paulrouget]

Is this message a warning or a hard error?

[sophiajt]

I only see this message

Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.

[sophiajt]

Otherwise the demo seems to work okay

[paulrouget]

But nothing shows up on Ctrl-L?

[sophiajt]

From inside the demo? It doesn't seem to do anything in the demo.

From the servoshell nothing shows up and I get the error.

[tschneidereit]

I debugged this some more, but only found out more weird stuff, no solution:

First off, the error does stem from the dialogs: Zenity is the Gnome library for handling dialogs.

If I remove everything from main.rs and replace it with the minimal amount of code to get tinyfiledialogs::input_box working, I still get the same symbol lookup error. If I then also remove libservo from the Cargo.toml dependencies, things work. So simply by compiling libservo, but not using it in any way, things break.

This is all quite weird, because the way tinyfiledialogs works is by invoking an external process and consuming the return value. In this case, there's a process invocation with this command line:

zenity --entry --title="Search or type URL" --text="Search or type URL" --hide-text

It is entirely unclear to me how that could possibly break in the way we see here, but it does.

[paulrouget]

@tschneidereit can you add this call to tinyfiledialog in servo itself (not in servoshell), here:

https://github.com/servo/servo/blob/7cb47f16361cee1a65edfa760510a07833ef689f/ports/glutin/window.rs#L1307

…replace this line with the tinyfiledialogs::input_box call, and build servo.

I'd like to see if this problem could be related to servoshell and the way we compile.

[tschneidereit]

@paulrouget I added the call at the beginning of fn main in ports/servo/main.rs - that should be equivalent in terms of testing to what you asked, right? In any case: that worked.

[paulrouget]

Interesting. The only thing I can think of is some magic the extra python scripts do in servo. Tomorrow I'll be push a branch that uses mach for servoshell. We'll see if that solves the issue.

[tschneidereit]

Ok, I figured out what's causing this: LD_LIBRARY_PATH is set to include a large amount of paths for servoshell and only two entries for servo. (See below.)

Executing the Zenity process with the same arguments as tinyfiledialogs does results in the same symbol not found error. If I set LD_LIBRARY_PATH to the same value it has in Servo, things work.

Now why this happens is another matter altogether.

servoshell:
LD_LIBRARY_PATH: /home/till/mozilla/servo/servoshell/target/debug/build/servo-freetype-sys-c65727b162a141a4/out/lib:/home/till/mozilla/servo/servoshell/target/debug/build/heartbeats-simple-sys-3f46ba774247e720/out/lib:/home/till/mozilla/servo/servoshell/target/debug/build/mozjs_sys-1fb02239c941f926/out/js/src:/home/till/mozilla/servo/servoshell/target/debug/build/harfbuzz-sys-4a543f86d202a6c6/out/lib:/home/till/mozilla/servo/servoshell/target/debug/build/miniz-sys-b1e8cc924066db2e/out:/home/till/mozilla/servo/servoshell/target/debug/build/servo-skia-771f656f5437c6bb/out/lib:/home/till/mozilla/servo/servoshell/target/debug/build/tinyfiledialogs-c5bb9a32d4fc13d0/out:/home/till/mozilla/servo/servoshell/target/debug/build/js-17f8b11551286240/out/lib:/home/till/mozilla/servo/servoshell/target/debug/build/backtrace-sys-3bfacdcf93426705/out/.libs:/home/till/mozilla/servo/servoshell/target/debug/build/fontsan-6afaf7e5bc8056a2/out/lib:/home/till/mozilla/servo/servoshell/target/debug/build/azure-007c878776fcb4b0/out/lib:/home/till/mozilla/servo/servoshell/target/debug/build/angle-a2b6291ebfcc6a10/out:/home/till/mozilla/servo/servoshell/target/debug:/home/till/mozilla/servo/servoshell/target/debug/deps:/home/till/.rustup/toolchains/nightly-2017-08-30-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib:/home/till/.rustup/toolchains/nightly-2017-08-30-x86_64-unknown-linux-gnu/lib

Servo:
LD_LIBRARY_PATH: /home/till/mozilla/servo/servo/.servo/rust/2017-08-30-alt/rustc-nightly-x86_64-unknown-linux-gnu/rustc/lib:/home/till/mozilla/servo/servo/.servo/rust/2017-08-30-alt/rustc-nightly-x86_64-unknown-linux-gnu/lib:

[tschneidereit]

Now why this happens is another matter altogether.

Because cargo run changes LD_LIBRARY_PATH in this way. Turns out running target/debug/servoshell manually was working all along ...

(For some definition of "working", but the dialog showed and submitting it caused navigation to happen.)

[paulrouget]

Related:

• https://users.rust-lang.org/t/subprocess-and-dynamic-library-linking-problem-interaction/7873
• Cargo binaries are not run in pristine environment rust-lang/cargo#2888

[paulrouget]

This should fix it: servo/rust-harfbuzz#80

Once this lands, I still need to update servo, and then servoshell.

[paulrouget]

Waiting on servo/servo#18410

[paulrouget]

Fixed.