From owner-freebsd-gecko@freebsd.org Mon Jun 17 04:20:03 2019 Return-Path: Delivered-To: freebsd-gecko@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B83A015D2C30 for ; Mon, 17 Jun 2019 04:20:03 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 588DF75DB2 for ; Mon, 17 Jun 2019 04:20:03 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 18F2A15D2C2F; Mon, 17 Jun 2019 04:20:03 +0000 (UTC) Delivered-To: gecko@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5D1815D2C2E for ; Mon, 17 Jun 2019 04:20:02 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 81A4775DAF; Mon, 17 Jun 2019 04:20:02 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id 59D3E17E7; Mon, 17 Jun 2019 04:20:02 +0000 (UTC) From: Jan Beich To: "Mikhail T." Cc: gecko@freebsd.org Subject: Re: Firefox and llvm References: <96bcddaf-f310-34b3-70c6-6a223f5f8b6c@aldan.algebra.com> <5zp5-yp43-wny@FreeBSD.org> <64325580-58fa-be6a-6045-58c5409ddb20@aldan.algebra.com> Date: Mon, 17 Jun 2019 06:19:59 +0200 In-Reply-To: (Mikhail T.'s message of "Sun, 16 Jun 2019 23:09:31 -0400") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 81A4775DAF X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.96 / 15.00]; TAGGED_RCPT(0.00)[thun]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_SHORT(-0.97)[-0.968,0]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-gecko@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gecko Rendering Engine issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 04:20:04 -0000 "Mikhail T." 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 [...]