Date: Mon, 17 Jun 2019 06:19:59 +0200 From: Jan Beich <jbeich@FreeBSD.org> To: "Mikhail T." <mi+thun@aldan.algebra.com> Cc: gecko@freebsd.org Subject: Re: Firefox and llvm Message-ID: <v9x4-j11s-wny@FreeBSD.org> In-Reply-To: <a1248947-bdb6-ddb8-5eb3-6485b91656e5@aldan.algebra.com> (Mikhail T.'s message of "Sun, 16 Jun 2019 23:09:31 -0400") References: <96bcddaf-f310-34b3-70c6-6a223f5f8b6c@aldan.algebra.com> <5zp5-yp43-wny@FreeBSD.org> <64325580-58fa-be6a-6045-58c5409ddb20@aldan.algebra.com> <y321-osmi-wny@FreeBSD.org> <a1248947-bdb6-ddb8-5eb3-6485b91656e5@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Mikhail T." <mi+thun@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
[...]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v9x4-j11s-wny>