Firefox and llvm

Jan Beich jbeich at FreeBSD.org
Mon Jun 17 04:20:04 UTC 2019


"Mikhail T." <mi+thun at aldan.algebra.com> writes:

> On 16.06.19 22:25, Jan Beich wrote:
>
>> clang-sys didn't support llvm80 when gecko@ switched to it. I'm not
>> sure myself why but maybe bindgen uses a subset of bindings that're
>> stable
>
> Perhaps, this is something the port's maintainers should research?

If bindgen wasn't compatible with a certain libclang version it'd crash
or produce invalid output thus abort firefox build. However, bindgen
doesn't work if libclang isn't installed at all. Firefox uses bundled
bindgen but a standalone should be easier to play with.

$ pkg install rust-bindgen
$ mv /usr/local/llvm* /tmp
$ RUST_BACKTRACE=1 bindgen /usr/include/Block.h
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:347:21
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:71
             at src/libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:197
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:211
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:474
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:381
   6: rust_begin_unwind
             at src/libstd/panicking.rs:308
   7: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
   8: core::panicking::panic
             at src/libcore/panicking.rs:49
   9: clang_sys::load_manually::build::dynamic::search_libclang_directories
  10: clang_sys::load_manually
  11: clang_sys::load
  12: bindgen::clang_version
  13: bindgen::main
  14: std::rt::lang_start::{{closure}}
  15: std::panicking::try::do_call
             at src/libstd/rt.rs:49
             at src/libstd/panicking.rs:293
  16: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:85
  17: std::rt::lang_start_internal
             at src/libstd/panicking.rs:272
             at src/libstd/panic.rs:388
             at src/libstd/rt.rs:48
  18: main
  19: _start
             at /usr/src/lib/csu/amd64/crt1.c:76

> Along with the possibility of switching lang/rust back to the llvm
> provided by the base (best) or installed by a port (second best)?

See https://svnweb.freebsd.org/changeset/ports/454983 and associated bugs.

>> Good luck. Make sure to test in a clean environment e.g., via poudriere
>
> Jan, this is the job of the port's maintainer... The current situation
> -- requiring a rebuild of LLVM twice -- is ridiculous, should never
> have come about, and should not remain for long. I hope, we agree on
> the first and the second, at least...

If you don't pay, don't help and don't do the homework why should I care?

>>> I can't see, what good llvm-objdump could do to the vast majority of users.
>> See https://hg.mozilla.org/mozilla-central/rev/53d93ee3ad84
>> While the commit was backed out the configure check wasn't, so maybe
>> the intent is to reland in future.
> So, it is not even being used?! And, if it were, it would only be for
> some build-time library-reading, which the port could disable...

dependentlibs.py doesn't appear to use on ELF platforms but mozbuild does.
That "library-reading" is responsible for loading bundled shlibs e.g.,

$ firefox example.com
XPCOMGlueLoad error for file /usr/local/lib/firefox/libxul.so:
Shared object "liblgpllibs.so" not found, required by "libxul.so"
Couldn't load XPCOM.

Please, file a bug upstream.

>>> And if it does something good, llvm-objdump is already part of base
>>> (at least, on this 12.0-STABLE laptop I'm trying to dress up)...
>> llvm-objdump is only installed when src.conf(5) has WITH_CLANG_EXTRAS.
>> Ports have to build against default base configuration.
>
> I don't have that knob defined on this 12.0 system, but llvm-objdump
> is installed anyway -- perhaps, on 12.0 it is on by default. At any
> rate, it is a) not used, b) not needed, c) is a small utility, which,
> if actually needed, could've been installed via a port of its own.

Indeed, https://svnweb.freebsd.org/changeset/base/310840 but Firefox
needs llvm-objdump >= 7.0 which would exclude FreeBSD 12.0.

$ /poudriere/jails/120amd64/usr/bin/llvm-objdump --private-headers \
  /usr/local/lib/firefox/libxul.so | fgrep NEEDED
$ /poudriere/jails/head-amd64/usr/bin/llvm-objdump --private-headers \
  /usr/local/lib/firefox/libxul.so | fgrep NEEDED
  NEEDED               liblgpllibs.so
  NEEDED               libmozgtk.so
  NEEDED               libmozwayland.so
[...]


More information about the freebsd-gecko mailing list