Closed Bug 1401093 Opened 7 years ago Closed 7 years ago

stylo doesnt build on 32-bits

Categories

(Core :: CSS Parsing and Computation, defect, P4)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox-esr52 --- unaffected
firefox55 --- wontfix
firefox56 --- wontfix
firefox57 --- affected
firefox58 --- affected

People

(Reporter: gaston, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [stylo])

Attachments

(1 file)

sequentialize bindgen tasks
560 bytes, patch
jbeich
: feedback-
Details | Diff | Splinter Review
Since stylo was enabled by default, the build is broken on OpenBSD/i386 which is 32-bits due to memory consumption of rust compiler (and yes, i've maxed out the system limits for the build user). Cf http://buildbot.rhaalovely.net/builders/mozilla-central-i386/builds/1031/steps/build/logs/stdio 34:09.86 error: Could not compile `style`. I don't know if this is a rust issue, or a stylo issue, or a build system issue, but if someday stylo is the only option for CSS, then that kills it on 32-bits systems.
Building m-c on i386: 73:06.90 Compiling style_traits v0.0.1 (file:///home/landry/src/m-c/servo/components/style_traits) 77:18.50 Compiling style v0.0.1 (file:///home/landry/src/m-c/servo/components/style) 77:45.02 Compiling webrender_bindings v0.1.0 (file:///home/landry/src/m-c/gfx/webrender_bindings) 93:51.33 error: Could not compile `style`. 93:51.39 93:51.39 To learn more, run the command again with --verbose. i have BUILD_VERBOSE_LOG=1 in .mozconfig so dunno what more is needed to have *verbose* logs for rustc...
i386 chroot on amd64 build fails here as well. Does Mozilla build on Linux via -m32 rather than 32bit chroot? gmake[1]: Entering directory 'obj-i386-unknown-freebsd10.3/toolkit/library/rust' force-cargo-library-build env RUSTFLAGS=' -C debuginfo=2 ' CARGO_TARGET_DIR=obj-i386-unknown-freebsd10.3/toolkit/library RUSTC=/usr/local/bin/rustc MOZ_SRC=/tmp/mozilla-central MOZ_DIST=obj-i386-unknown-freebsd10.3/dist LIBCLANG_PATH="/usr/local/llvm40/lib" CLANG_PATH="/usr/local/llvm40/bin/clang" PKG_CONFIG_ALLOW_CROSS=1 RUST_BACKTRACE=full MOZ_TOPOBJDIR=obj-i386-unknown-freebsd10.3 MOZ_CARGO_WRAP_LDFLAGS="-pthread -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-rpath-link,obj-i386-unknown-freebsd10.3/dist/bin -Wl,-rpath-link,/usr/local/lib" MOZ_CARGO_WRAP_LD=" /usr/local/bin/clang40 -std=gnu99" CARGO_TARGET_I686_UNKNOWN_FREEBSD_LINKER=build/cargo-linker /usr/local/bin/cargo rustc --release --frozen --manifest-path toolkit/library/rust/Cargo.toml --lib --target=i686-unknown-freebsd --features "servo bindgen quantum_render cubeb_pulse_rust no-static-ideograph-encoder-tables" -- Compiling style v0.0.1 (file://servo/components/style) error: failed to run custom build command for `style v0.0.1 (file://servo/components/style)` process didn't exit successfully: `obj-i386-unknown-freebsd10.3/toolkit/library/release/build/style-13a95b71a240d8e6/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)
I don't think 32-bit hosts have been valid build hosts for a while, typically because linkers couldn't handle libxul--our linux32 and win32 builds have been cross-compiled from their 64-bit counterparts for some time now. Has that not been the case on *BSD?
As of present, FreeBSD i386 packages for various releases are built in jails on beefy amd64 boxes running bleeding edge version of FreeBSD (for jail/chroot only kernel matters). -m32 isn't used because it was broken in the past and due to lack of multi-arch package support (e.g., installing 32bit and 64bit libs the same time). Downstream builds pass --disable-debug-symbols, so linking libxul.so isn't an issue yet. time(1) for cargo build shows ru_maxrss is around 320 Mb. Landry, can you check ru_maxrss as well? If the memory usage is as low then, I guess, it maybe another bindgen issue.
No longer blocks: 1366050
See Also: → 1366050
(In reply to Nathan Froyd [:froydnj] from comment #3) > I don't think 32-bit hosts have been valid build hosts for a while, > typically because linkers couldn't handle libxul--our linux32 and win32 > builds have been cross-compiled from their 64-bit counterparts for some time > now. Has that not been the case on *BSD? For OpenBSD, i've always built natively on i386, using tricks like LDFLAGS="-Wl,--no-keep-memory" for example (we still use an ancient ld/binutils) - the day native builds arent possible anymore, then i'll drop support for firefox on i386. Our policy explicitely makes native building mandatory, there's no infrastructure to cross-compile third-party software, and the cross-compiling infra in the basesystem is only here to bring a new architecture to life - its use is severely frowned upon outside of this particular case.
> i386 chroot on amd64 build fails here as well. Does Mozilla build on Linux via -m32 rather than 32bit chroot? Yes, all of our build hosts are 64-bit. Even without Rust code in play linking libxul frequently maxes out the available address space on 32-bit systems. I don't think we should put any effort into supporting 32-bit build hosts.
Well, linux distros tend to not cross-build so they would build 32-bits binaries on 32-bits OSes. What I do on Debian is add -Wl,--reduce-memory-overheads -Wl,--no-keep-memory to LDFLAGS. Maybe we could do that automatically.
as found out by semarie, commenting out https://dxr.mozilla.org/mozilla-central/source/config/rules.mk#927 helps stylo on x86. So maybe i'll try with the following: # XXX hack to work around dsymutil failing on cross-OSX builds (bug 1380381) ifeq ($(HOST_OS_ARCH)-$(OS_ARCH),Linux-Darwin) default_rustflags += -C debuginfo=1 else +ifeq ($(OS_ARCH)-$(CPU_ARCH),OpenBSD-x86) +default_rustflags += -C debuginfo=1 +else default_rustflags += -C debuginfo=2 endif +endif I didnt know about --reduce-memory-overheads, only --no-keep-memory - i'll also tr this.
And looking a bit more, shouldnt this debuginfo stuff be wrapped inside MOZ_DEBUG_RUST ?
No, this is similar to --enable-debug vs. --enable-debug-symbols. MOZ_DEBUG_RUST controls whether we enable debug assertions in Rust code. We could change that so setting --disable-debug-symbols would not generate Rust debug symbols, which would be reasonable.
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #10) > No, this is similar to --enable-debug vs. --enable-debug-symbols. > MOZ_DEBUG_RUST controls whether we enable debug assertions in Rust code. We > could change that so setting --disable-debug-symbols would not generate Rust > debug symbols, which would be reasonable. That would definitely work for me.
(In reply to Landry Breuil (:gaston) from comment #8) > +ifeq ($(OS_ARCH)-$(CPU_ARCH),OpenBSD-x86) Can probably be simplified to "ifeq ($(HOST_CPU_ARCH),x86)" if it affects all native i386 builds. > +default_rustflags += -C debuginfo=1 Doesn't help in FreeBSD i386 chroot on amd64 host.
Blocks: stylo-tooling
status-firefox58: --- → affected
Priority: -- → P4
Whiteboard: [stylo]
Interestingly, i gave another shot to stylo on 57.0b3 with hacks for bug 1401093 and bug 1341234, but it fails the same on i386 and amd64: Compiling style v0.0.1 (file:///build/obj/ports/firefox-57.0beta3/firefox-57.0b3/servo/components/style) error: failed to run custom build command for `style v0.0.1 (file:///build/obj/ports/firefox-57.0beta3/firefox-57.0b3/servo/components/style)` process didn't exit successfully: `/build/obj/ports/firefox-57.0beta3/build-i386/toolkit/library/release/build/style-e51f305bc1e05173/build-script-build` (exit code: 101) ... --- stderr thread '<unnamed>' panicked at 'TranslationUnit::parse failed', /usr/obj/ports/rust-1.20.0/rustc-1.20.0-src/src/libcore/option.rs:819:4 stack backtrace: 0: 0x1904cc0e - <unknown> 1: 0x19049b55 - <unknown>
And thanks to :semarie, it *might* be a rust-bindgen issue (related to the clang version we're using, 5.0 here ? doubt it as successfull builds of m-b are done with ports clang, and failing builds from the packaging infra are done with ports clang too..) - he linked me to https://github.com/rust-lang-nursery/rust-bindgen/issues/340.
(In reply to Landry Breuil (:gaston) from comment #15) > And thanks to :semarie, it *might* be a rust-bindgen issue (related to the > clang version we're using, 5.0 here ? doubt it as successfull builds of m-b > are done with ports clang, and failing builds from the packaging infra are > done with ports clang too..) - he linked me to > https://github.com/rust-lang-nursery/rust-bindgen/issues/340. I'm using clang trunk, so that's probably not the case. That panic happens whenever clang parsing fails, which is usually because you're pointing bindgen to the wrong file.
Note also that something like the attached patch may help with memory usage during the bindgen phase (if it is an issue, someone just asked on IRC with an OOM on FreeBSD i386).
If OOM is unrelated, bug 1406952 may be the culprit. TL;DR, the clang-sys library is passing structs where libclang expects integers. This is fine everywhere but linux32 (or similar ABIs), so we need to fix it... I proposed a fix for clang-sys, and will update bindgen in mozilla-central once it lands.
Comment on attachment 8916787 [details] [diff] [review] sequentialize bindgen tasks This patch doesn't help on FreeBSD i386. style build still dies with SIGSEGV: invalid memory reference
Attachment #8916787 - Flags: feedback-
(In reply to Emilio Cobos Álvarez [:emilio] from comment #18) > If OOM is unrelated, bug 1406952 may be the culprit. KyleMayes/clang-sys#66 (applied on FF57 as http://sprunge.us/NdfT) doesn't help on FreeBSD i386 as well. ;(
(In reply to Jan Beich from comment #20) > (In reply to Emilio Cobos Álvarez [:emilio] from comment #18) > > If OOM is unrelated, bug 1406952 may be the culprit. > KyleMayes/clang-sys#66 (applied on FF57 as http://sprunge.us/NdfT) doesn't > help on FreeBSD i386 as well. ;( Can you get a stack trace or something like that? I'm not sure what dark magic needed to happen to get custom modifications to crates work in a checkout. But anyway, if that's not the culprit (I'm pretty sure that's it for bug 1406952, but there may be other problems), I'd need a stack or something to try to figure out.
Flags: needinfo?(jbeich)
(In reply to Emilio Cobos Álvarez [:emilio] from comment #21) > (In reply to Jan Beich from comment #20) > > (In reply to Emilio Cobos Álvarez [:emilio] from comment #18) > > > If OOM is unrelated, bug 1406952 may be the culprit. > > KyleMayes/clang-sys#66 (applied on FF57 as http://sprunge.us/NdfT) doesn't > > help on FreeBSD i386 as well. ;( > > Can you get a stack trace or something like that? Only with non-debug symbols. ?? below probably points to a symbol in libclang. IIRC, llvm* packages don't build with debug symbols on i386 due to OOM. (gdb) bt #0 0xfbbf8338 in ?? () #1 0x0114e383 in clang_sys::clang_formatDiagnostic () #2 0x01077b7d in bindgen::clang::Diagnostic::format () #3 0x010aaf52 in bindgen::Bindings::generate () #4 0x010a9a44 in bindgen::Builder::generate () #5 0x010286d5 in build_script_build::build_gecko::bindings::write_binding_file () #6 0x010312cf in build_script_build::build_gecko::bindings::generate_bindings () #7 0x013031e6 in __rust_maybe_catch_panic () #8 0x010202e8 in <F as alloc::boxed::FnBox<A>>::call_box () #9 0x012f4b0d in std::sys::imp::thread::Thread::new::thread_start () #10 0x214a63ce in thread_start (curthread=0x22214780) at /usr/src/lib/libthr/thread/thr_create.c:288 #11 0x00000000 in ?? () (gdb) i thr Id Target Id Frame * 1 LWP 101504 "build-script-build" 0xfbbf8338 in ?? () 2 LWP 101749 "build-script-build" _umtx_op_err () at /usr/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36 3 LWP 100832 "build-script-build" _umtx_op_err () at /usr/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36 4 LWP 101475 "build-script-build" _umtx_op_err () at /usr/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36 5 LWP 101651 "build-script-build" 0x2324b736 in ?? () from /usr/local/llvm40/lib/libclang.so.4.0 6 LWP 101917 "build-script-build" 0x2396b815 in ?? () from /usr/local/llvm40/lib/libclang.so.4.0 > I'm not sure what dark magic needed to happen to get custom modifications to > crates work in a checkout. Just patch Cargo.lock and .cargo-checksum.json. The build helpfully points out when those are incorrect. I don't remember how to use [replace].
Flags: needinfo?(jbeich)
Hi! I confirm that neither the patch for bug 1406952 nor the one for this bug worked for me on FreeBSD/i386. I will try to get more informations from the failure, but probably not much more than what Jan already posted.
(In reply to Jan Beich from comment #22) > Only with non-debug symbols. ?? below probably points to a symbol in > libclang. IIRC, llvm* packages don't build with debug symbols on i386 due to > OOM. That's ok, thanks! So that's the entry point we're supposed to be fixing with that patch, so that's not great... Can you maybe panic! in that bindgen function, and double-check your code runs? If so, can you skip executing this block (or a similar-looking one, we're not using upstream): https://github.com/rust-lang-nursery/rust-bindgen/blob/4e74c3926154174856542f172ed81169420b62ba/src/lib.rs#L1705 And see if it works / where do you crash next? We can definitely hack around this in bindgen if needed, but I'd expect the clang-sys patch to fix the bug... Anyway that call should be one of the few affected functions I'd think (if the problem is what I think it is), so maybe it even works properly just commenting that block. I'd expect this crash to reproduce using bindgen master on any file that emits a warning or something like that, so if you could be able to reproduce, that'd be a nice reduced testcase. I can try to setup a 32 bits vm or something next week, but if we could figure this out without me having to do it that'd be nice.
I've built llvm40 with debug symbols. On tmpfs it took just ~115Gb of RAM, so here's just the useful part: https://people.freebsd.org/~jbeich/10.3R-i386-debug-llvm40-4.0.1_2.libclang.so.4.0.xz SHA256 3ec739f8f13789025b4c5952dd1184062b1b061dc13524cddbb9e7e92612ce3b (In reply to Emilio Cobos Álvarez [:emilio] from comment #24) > Can you maybe panic! in that bindgen function, In bindgen::clang::Diagnostic::format? Despite -C debuginfo=2 (as part of --enable-debug) neither libbacktrace nor gdb seem to show line numbers. thread '<unnamed>' panicked at 'explicit panic', /wrkdirs/usr/ports/www/firefox/work/firefox-57.0b7/third_party/rust/bindgen-0.29.0/src/clang.rs:1410:8 stack backtrace: 0: 0x12f03fe - std::sys::imp::backtrace::tracing::imp::unwind_backtrace::ha928530fca117cec 1: 0x12ed345 - std::sys_common::backtrace::_print::h3a5dd89434e27c7c 2: 0x12f4cfa - std::panicking::default_hook::{{closure}}::h0fa338d74a281533 3: 0x12f4a8f - std::panicking::default_hook::h790ddb06fb7ff5ea 4: 0x12f51dc - std::panicking::rust_panic_with_hook::h47478d54f505f943 5: 0x103878b - std::panicking::begin_panic_new::hb84e37285d641e8f 6: 0x10ad75c - bindgen::Bindings::generate::h827631c83bef2b73 7: 0x10a9953 - bindgen::Builder::generate::h1d7cd688c0dc05ff 8: 0x1028714 - build_script_build::build_gecko::bindings::write_binding_file::hed16a260463addbf 9: 0x102d161 - build_script_build::build_gecko::bindings::generate_structs::hfc0e563274977677 10: 0x1302a95 - __rust_maybe_catch_panic 11: 0x101ffe7 - <F as alloc::boxed::FnBox<A>>::call_box::h1938dac815611e09 12: 0x12f43bc - std::sys::imp::thread::Thread::new::thread_start::h319db42e671cf177 13: 0x214ab43d - <unknown> at /usr/src/lib/libthr/thread/thr_create.c:288 14: 0x0 - <unknown> > and double-check your code runs? Run after panic!() ? > can you skip executing this block: > https://github.com/rust-lang-nursery/rust-bindgen/blob/ > 4e74c3926154174856542f172ed81169420b62ba/src/lib.rs#L1705 Program terminated with signal SIGSEGV, Segmentation fault. #0 0x2182137a in strlen (str=0xb7a8 <error: Cannot access memory at address 0xb7a8>) at /usr/src/lib/libc/string/strlen.c:100 100 va = (*lp - mask01); [Current thread is 1 (LWP 101497)] (gdb) bt #0 0x2182137a in strlen (str=0xb7a8 <error: Cannot access memory at address 0xb7a8>) at /usr/src/lib/libc/string/strlen.c:100 #1 0x012e60e8 in std::ffi::c_str::CStr::from_ptr () #2 0x0107684d in bindgen::clang::File::name () #3 0x010715e5 in bindgen::clang::Cursor::is_builtin () #4 0x010ade21 in bindgen::parse_one () #5 0x010730df in bindgen::clang::visit_children () #6 0x22f770e0 in clang::cxcursor::CursorVisitor::Visit (this=0xfbbf8068, Cursor=..., CheckedRegionOfInterest=false) at /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/libclang/CIndex.cpp:209 #7 0x22fc29d7 in clang::cxcursor::CursorVisitor::visitPreprocessedEntities<clang::PreprocessingRecord::iterator> (this=0xfbbf8068, First=..., Last=..., PPRec=..., FID=...) at /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/libclang/CIndex.cpp:461 #8 0x22f79def in clang::cxcursor::CursorVisitor::visitPreprocessedEntitiesInRegion ( this=0xfbbf8068) at /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/libclang/CIndex.cpp:437 #9 0x22f78eed in clang::cxcursor::CursorVisitor::VisitChildren (this=0xfbbf8068, Cursor=...) at /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/libclang/CIndex.cpp:540 #10 0x22f8f882 in clang_visitChildren (parent=..., visitor=0x1073090 <bindgen::clang::visit_children>, client_data=0xfbbf82e8) at /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/libclang/CIndex.cpp:4159 #11 0x011524da in clang_sys::clang_visitChildren () #12 0x010aab96 in bindgen::Bindings::generate () #13 0x010a9624 in bindgen::Builder::generate () #14 0x010286f5 in build_script_build::build_gecko::bindings::write_binding_file () #15 0x010312ef in build_script_build::build_gecko::bindings::generate_bindings () #16 0x01302346 in __rust_maybe_catch_panic () #17 0x01020308 in <F as alloc::boxed::FnBox<A>>::call_box () #18 0x012f3c6d in std::sys::imp::thread::Thread::new::thread_start () #19 0x214aa43e in thread_start (curthread=0x22214780) at /usr/src/lib/libthr/thread/thr_create.c:288 #20 0x00000000 in ?? () (gdb) i thr Id Target Id Frame * 1 LWP 101497 "build-script-build" 0x2182137a in strlen ( str=0xb7a8 <error: Cannot access memory at address 0xb7a8>) at /usr/src/lib/libc/string/strlen.c:100 2 LWP 102100 "build-script-build" _umtx_op_err () at /usr/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36 3 LWP 100783 "build-script-build" _umtx_op_err () at /usr/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36 4 LWP 101444 "build-script-build" _umtx_op_err () at /usr/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36 5 LWP 101505 "build-script-build" 0x240ac608 in clang::Sema::DiagnoseUseOfDecl ( this=0x22af0000, D=0x2c3d4100, Loc=..., UnknownObjCClass=0x0, ObjCPropertyAccess=false) at /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/lib/Sema/SemaExpr.cpp:384 6 LWP 101917 "build-script-build" 0x23162915 in llvm::FoldingSetNodeID::AddBoolean ( this=0xfa7f20a8, B=false) at /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/include/llvm/ADT/FoldingSet.h:336 (gdb) thr a 5 bt Thread 5 (LWP 101505): #0 0x240ac608 in clang::Sema::DiagnoseUseOfDecl (this=0x22af0000, D=0x2c3d4100, Loc=..., UnknownObjCClass=0x0, ObjCPropertyAccess=false) at /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/lib/Sema/SemaExpr.cpp:384 #1 0x240c41b7 in clang::Sema::BuildDeclarationNameExpr (this=0x22af0000, SS=..., NameInfo=..., D=0x2c3d4100, FoundD=0x0, TemplateArgs=0x0, AcceptInvalidDecl=false) at /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/lib/Sema/SemaExpr.cpp:2876 #2 0x2487b65b in clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::RebuildDeclRefExpr (this=0xfaff46b0, QualifierLoc=..., VD=0x2c3d4100, NameInfo=..., TemplateArgs=0x0) at /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/lib/Sema/TreeTransform.h:2001 [...] > (or a similar-looking one, What? No other place calls bindgen::clang::Diagnostic::format. > we're not using upstream) FF57 has 2 copies of bindgen: 0.30.0 and 0.29.0. Stylo only uses 0.29.0. > We can definitely hack around this in bindgen if needed Are you implying upstream (bindgen, not firefox) doesn't run regression tests on a 32bit platform, only targets it while using 64bit toolchain? > I'd expect this crash to reproduce using bindgen master on any file that > emits a warning or something like that, so if you could be able to > reproduce, that'd be a nice reduced testcase. My attempt to update bindgen via "./mach vendor rust" failed. Do you want a backtrace for 0.30.0 despite it being ~1.5 months old? gmake[1]: Entering directory '/wrkdirs/usr/ports/www/firefox/work/firefox-57.0b7/obj-i386-unknown-freebsd10.3/toolkit/library/rust' force-cargo-library-build env RUSTC_BOOTSTRAP=1 RUSTFLAGS=' -C debuginfo=2 ' CARGO_TARGET_DIR=/wrkdirs/usr/ports/www/firefox/work/firefox-57.0b7/obj-i386-unknown-freebsd10.3/toolkit/library RUSTC=/usr/local/bin/rustc MOZ_SRC=/wrkdirs/usr/ports/www/firefox/work/firefox-57.0b7 MOZ_DIST=/wrkdirs/usr/ports/www/firefox/work/firefox-57.0b7/obj-i386-unknown-freebsd10.3/dist LIBCLANG_PATH="/usr/local/llvm40/lib" CLANG_PATH="/usr/local/llvm40/bin/clang" PKG_CONFIG_ALLOW_CROSS=1 RUST_BACKTRACE=full MOZ_TOPOBJDIR=/wrkdirs/usr/ports/www/firefox/work/firefox-57.0b7/obj-i386-unknown-freebsd10.3 MOZ_CARGO_WRAP_LDFLAGS="-pthread -Wl,--as-needed -fstack-protector -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-rpath-link,/wrkdirs/usr/ports/www/firefox/work/firefox-57.0b7/obj-i386-unknown-freebsd10.3/dist/bin -Wl,-rpath-link,/usr/local/lib" MOZ_CARGO_WRAP_LD=" /usr/local/bin/clang40 -std=gnu99" CARGO_TARGET_I686_UNKNOWN_FREEBSD_LINKER=/wrkdirs/usr/ports/www/firefox/work/firefox-57.0b7/build/cargo-linker /usr/local/bin/cargo rustc --release --frozen --manifest-path /wrkdirs/usr/ports/www/firefox/work/firefox-57.0b7/toolkit/library/rust/Cargo.toml --lib --target=i686-unknown-freebsd --features "servo bindgen cubeb_pulse_rust simd-accel no-static-ideograph-encoder-tables" -- -C lto error: failed to load source for a dependency on `encoding_c` Caused by: Unable to update registry https://github.com/rust-lang/crates.io-index Caused by: failed to update replaced source `registry https://github.com/rust-lang/crates.io-index` Caused by: failed to decode `.cargo-checksum.json` of bindgen v0.30.1 Caused by: invalid type: unit value, expected a string at line 1 column 96051 > I can try to setup a 32 bits vm or something next week, but if we could > figure this out without me having to do it that'd be nice. Why not debootstrap + chroot on Linux or poudriere + jexec on FreeBSD?
(In reply to Jan Beich from comment #25) > > I can try to setup a 32 bits vm or something next week, but if we could > > figure this out without me having to do it that'd be nice. > > Why not debootstrap + chroot on Linux or poudriere + jexec on FreeBSD? I detailed my version of setting this up on Linux for Stylo, might be useful if Emilio wants to try as well: https://convolv.es/blog/2017/08/25/building-firefox-for-linux-32-bit/
bindgen 0.29.1 (unlike 0.30) inludes KyleMayes/clang-sys#66, so here's an attempt to build with it. $ sed -i '' 's/0\.29/0.29.1/' servo/components/style/Cargo.toml $ ./mach vendor rust $ ./mach build [...] Compiling clang-sys v0.21.0 Compiling bindgen v0.29.1 [...] Compiling style v0.0.1 (file:///wrkdirs/usr/ports/www/firefox/work/firefox-57.0b7/servo/components/style) error: failed to run custom build command for `style v0.0.1 (file:///wrkdirs/usr/ports/www/firefox/work/firefox-57.0b7/servo/components/style)` process didn't exit successfully: `/wrkdirs/usr/ports/www/firefox/work/firefox-57.0b7/obj-i386-unknown-freebsd10.3/toolkit/library/release/build/style-345909bf923bb20f/build-script-build` (signal: 11, SIGSEGV: invalid memory reference) Program terminated with signal SIGSEGV, Segmentation fault. #0 0xfbbf8338 in ?? () [Current thread is 1 (LWP 100296)] (gdb) bt #0 0xfbbf8338 in ?? () #1 0x23032cae in clang_formatDiagnostic (Diagnostic=0xfbbf8138, Options=580117040) at /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/libclang/CIndexDiagnostic.cpp:254 #2 0x0114e3d3 in clang_sys::clang_formatDiagnostic () #3 0x01077bcd in bindgen::clang::Diagnostic::format () #4 0x010aafa2 in bindgen::Bindings::generate () #5 0x010a9a94 in bindgen::Builder::generate () #6 0x01028725 in build_script_build::build_gecko::bindings::write_binding_file () #7 0x0103131f in build_script_build::build_gecko::bindings::generate_bindings () #8 0x01303236 in __rust_maybe_catch_panic () #9 0x01020338 in <F as alloc::boxed::FnBox<A>>::call_box () #10 0x012f4b5d in std::sys::imp::thread::Thread::new::thread_start () #11 0x214ab43e in thread_start (curthread=0x22214780) at /usr/src/lib/libthr/thread/thr_create.c:288 #12 0x00000000 in ?? () (gdb) f 1 #1 0x23032cae in clang_formatDiagnostic (Diagnostic=0xfbbf8138, Options=580117040) at /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/libclang/CIndexDiagnostic.cpp:254 254 CXDiagnosticSeverity Severity = clang_getDiagnosticSeverity(Diagnostic); (gdb) i loc Severity = 5 Str = {<llvm::SmallVector<char, 256>> = {<llvm::SmallVectorImpl<char>> = {<llvm::SmallVectorTemplateBase<char, true>> = {<llvm::SmallVectorTemplateCommon<char, void>> = {<llvm::SmallVectorBase> = { BeginX = 0x2302e112 <llvm::RefCountedBase<clang::DiagnosticOptions>::Release() const+178>, EndX = 0x22812580, CapacityX = 0x2b2c5c7c}, FirstEl = {<llvm::AlignedCharArray<1, 1>> = { buffer = "\240"}, <No data fields>}}, <No data fields>}, <No data fields>}, Storage = {InlineElts = {{<llvm::AlignedCharArray<1, 1>> = { buffer = "\177"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\277"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\373"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\036"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\340"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\002"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "#"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\200"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "%"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\201"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "@"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\200"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\277"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\373"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\200"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "%"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\201"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "|"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\\"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ","}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "+"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\200"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "%"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\201"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ">"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\364"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "0"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\001"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "|"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\\"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ","}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "+"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "|"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\\"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ","}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "+"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\300"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\177"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\277"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\373"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "V"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\340"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\002"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "#"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\200"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "%"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\201"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\200"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "%"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\201"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "|"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\\"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ","}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "+"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\334"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\177"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\277"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\373"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\036"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\340"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\002"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "#"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\200"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "%"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\201"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "X"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\200"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\277"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\373"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "|"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\\"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ","}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "+"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "X"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\200"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\277"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\373"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "|"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\\"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ","}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "+"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\360"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\177"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\277"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\373"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\260"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\202"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "+"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "X"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\200"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\277"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "@"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "@"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\200"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\030"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\221"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = " "}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\200"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\030"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\221"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\321"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\002"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "1"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\001"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\200"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\273"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\217"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\200"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\030"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\221"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = " "}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "@"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>} <repeats 11 times>, {<llvm::AlignedCharArray<1, 1>> = { buffer = "@"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\030"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\221"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\024"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\200"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\202"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "@"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "|"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "h"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "$"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\004"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "@"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = ""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\200"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\273"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\217"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\364"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\357"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "G"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\001"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\200"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "G"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "!"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\200"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "G"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "!"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\200"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "G"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "!"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\""}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "t"}, <No data fields>}, {<llvm::AlignedCharArray<1, 1>> = { buffer = "\200"}, <No data fields>}...}}}, <No data fields>} Out = {<llvm::raw_pwrite_stream> = {<llvm::raw_ostream> = {_vptr$raw_ostream = 0x2b8180e0, OutBufStart = 0x2b82b000 "H>(+", OutBufEnd = 0xfbbf7ff8 "\200\030\221\"\321\002\061\001\200\273\217\"\200\030\221\" ", OutBufCur = 0x2303231f <clang::cxdiag::lazyCreateDiags(CXTranslationUnitImpl*, bool)+63> "\211D$p\213D$x\201x\f", BufferMode = (unknown: 729907424)}, <No data fields>}, OS = @0xfbbf7fac} Text = {data = 0x2b8134a0, private_flags = 4223631160}
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #26) > https://convolv.es/blog/2017/08/25/building-firefox-for-linux-32-bit/ [...] >(host) $ rustup target add i686-unknown-linux-gnu Would this build i686 or x86_64 bindgen? Firefox compiles some parts for host and cross-compiles others for target. I suspect, bindgen is one of the former. If so one needs to build *inside* chroot, using 32bit toolchain.
(In reply to Jan Beich from comment #28) > (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #26) > > https://convolv.es/blog/2017/08/25/building-firefox-for-linux-32-bit/ > [...] > >(host) $ rustup target add i686-unknown-linux-gnu > > Would this build i686 or x86_64 bindgen? Firefox compiles some parts for > host and cross-compiles others for target. I suspect, bindgen is one of the > former. If so one needs to build *inside* chroot, using 32bit toolchain. Ah yes, I believe my setup would build and run bindgen on the 64-bit host, but instruct it to emit files targeting 32-bit. So, perhaps it's not an exact fit for the problem here.
(In reply to Jan Beich from comment #25) > My attempt to update bindgen via "./mach vendor rust" failed. [...] > Caused by: > failed to decode `.cargo-checksum.json` of bindgen v0.30.1 > > Caused by: > invalid type: unit value, expected a string at line 1 column 96051 For some reason, Cargo uses "package: null" for git dependencies, only to barf later. I've used garbage value and dropped --frozen but no joy: Compiling style v0.0.1 (file:///wrkdirs/usr/ports/www/firefox/work/firefox-57.0b7/servo/components/style) error[E0599]: no method named `constified_enum` found for type `bindgen::Builder` in the current scope --> /wrkdirs/usr/ports/www/firefox/work/firefox-57.0b7/servo/components/style/build_gecko.rs:408:63 | 408 | .handle_str_items("constified-enums", |b, item| b.constified_enum(item)) | ^^^^^^^^^^^^^^^
Does Rust or bindgen assume 16 byte stack alignment on i386? https://lists.freebsd.org/pipermail/freebsd-current/2012-November/037563.html https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496 $ git clone https://github.com/rust-lang-nursery/rust-bindgen/ $ git describe --tags v0.30.0-192-gd5a5c50 $ cargo test --verbose [...] running 375 tests test dump_preprocessed_input ... ok error: process didn't exit successfully: `/tmp/rust-bindgen/target/debug/deps/tests-b55c1668a1a3929d` (signal: 11, SIGSEGV: invalid memory reference) Thread 3 "header_16_byte_alig" received signal SIGSEGV, Segmentation fault. [Switching to LWP 100872 of process 73209] clang::cxstring::createRef (String=...) at /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/libclang/CXString.cpp:88 88 if (!String.empty() && String.data()[String.size()] != 0) (gdb) info locals Result = {data = 0x23f8f020 <clang_getFileName(CXFile)>, private_flags = 742646208} (gdb) list 83 84 // FIXME: This is doing a one past end read, and should be removed! For memory 85 // we don't manage, the API string can become unterminated at any time outside 86 // our control. 87 88 if (!String.empty() && String.data()[String.size()] != 0) 89 return createDup(String); 90 91 CXString Result; 92 Result.data = String.data(); (gdb) backtrace #0 clang::cxstring::createRef (String=...) at /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/libclang/CXString.cpp:88 #1 0x23f8f09d in clang_getFileName (SFile=0xfbdf6320) at /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/libclang/CIndex.cpp:4014 #2 0x01b204da in clang_sys::clang_getFileName () #3 0x0169e0cb in bindgen::clang::File::name () #4 0x016938cd in bindgen::clang::Cursor::is_builtin () #5 0x017bbd2a in bindgen::filter_builtins () #6 0x017bbe2c in bindgen::parse_one () #7 0x017bc872 in bindgen::parse::{{closure}}::{{closure}} () #8 0x01698b59 in bindgen::clang::visit_children () #9 0x23f770e0 in clang::cxcursor::CursorVisitor::Visit (this=0xfbdf6c60, Cursor=..., CheckedRegionOfInterest=true) at /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/libclang/CIndex.cpp:209 #10 0x23f7b553 in clang::cxcursor::CursorVisitor::handleDeclForVisitation (this=0xfbdf6c60, D= 0x2c48a8d0) at /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/libclang/CIndex.cpp:666 #11 0x23f7b70a in clang::cxcursor::CursorVisitor::VisitDeclContext (this=0xfbdf6c60, DC=0x2c48a17c) at /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/libclang/CIndex.cpp:627 #12 0x23f78e84 in clang::cxcursor::CursorVisitor::VisitChildren (this=0xfbdf6c60, Cursor=...) at /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/libclang/CIndex.cpp:532 #13 0x23f8f882 in clang_visitChildren (parent=..., visitor=0x1698970 <bindgen::clang::visit_children>, client_data=0xfbdf6e08) at /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/libclang/CIndex.cpp:4159 #14 0x01b22c1c in clang_sys::clang_visitChildren () #15 0x016961c0 in bindgen::clang::Cursor::visit () #16 0x017bc8ec in bindgen::parse::{{closure}} () #17 0x0176d4f0 in bindgen::ir::context::BindgenContext::with_module () #18 0x017bc4df in bindgen::parse () #19 0x017b9d3b in bindgen::Bindings::generate () #20 0x017b5ca3 in bindgen::Builder::generate () #21 0x011541b8 in tests::compare_generated_header () #22 0x0117acad in tests::header_16_byte_alignment_1_0_h::{{closure}} () #23 0x01073d99 in core::result::Result<core::option::Option<bindgen::Builder>, std::io::error::Error>::and_then<core::option::Option<bindgen::Builder>,std::io::error::Error,(),closure> (self=..., op=...) at /wrkdirs/usr/ports/lang/rust/work/rustc-1.20.0-src/src/libcore/result.rs:602 #24 0x0117a965 in tests::header_16_byte_alignment_1_0_h () #25 0x019f5d8f in test::__rust_begin_short_backtrace () #26 0x019e540a in <F as test::FnBox<T>>::call_box () #27 0x019d78a9 in std::panicking::try::do_call () #28 0x01ba9cc6 in __rust_maybe_catch_panic () #29 0x019d6cd1 in std::sys_common::backtrace::__rust_begin_short_backtrace () #30 0x019d7922 in std::panicking::try::do_call () #31 0x01ba9cc6 in __rust_maybe_catch_panic () #32 0x019decdf in <F as alloc::boxed::FnBox<A>>::call_box () #33 0x01b9b3fd in std::sys::imp::thread::Thread::new::thread_start () #34 0x21ef243e in thread_start (curthread=0x22a14500) at /usr/src/lib/libthr/thread/thr_create.c:288 #35 0x00000000 in ?? () (gdb) info threads Id Target Id Frame 1 LWP 101357 of process 73209 _umtx_op_err () at /usr/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36 * 3 LWP 100872 of process 73209 "header_16_byte_alig" clang::cxstring::createRef (String=...) at /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/tools/clang/tools/libclang/CXString.cpp:88 4 LWP 100874 of process 73209 "header_16_byte_alig" 0x24709fb1 in llvm::PointerIntPair<llvm::MemoryBuffer*, 2u, unsigned int, llvm::PointerLikeTypeTraits<llvm::MemoryBuffer*>, llvm::PointerIntPairInfo<llvm::MemoryBuffer*, 2u, llvm::PointerLikeTypeTraits<llvm::MemoryBuffer*> > >::getPointer (this=0xfbbf5088) at /wrkdirs/usr/ports/devel/llvm40/work/llvm-4.0.1.src/include/llvm/ADT/PointerIntPair.h:56 5 LWP 100890 of process 73209 "header_381_decltype" _umtx_op_err () at /usr/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36 et () 7 LWP 100929 of process 73209 "header_annotation_h" _umtx_op_err () at /usr/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36 8 LWP 100934 of process 73209 "header_anon_enum_hp" _poll () at _poll.S:3 9 LWP 100957 of process 73209 "header_anon_enum_tr" _read () at _read.S:3 10 LWP 102032 of process 73209 "header_anon_enum_wh" _poll () at _poll.S:3 14 LWP 102053 of process 73209 memcmp () at /usr/src/lib/libc/i386/string/memcmp.S:52 15 LWP 102054 of process 73209 0x01bb9882 in arena_run_tree_remove (rbtree=0x22849ff8, node=0x2ca017c8) at /wrkdirs/usr/ports/lang/rust/work/rustc-1.20.0-src/src/liballoc_jemalloc/../jemalloc/src/arena.c:76 (gdb) info registers eax 0xfbdf6270 -69246352 ecx 0x2c43e1c0 742646208 edx 0x2c40c260 742441568 ebx 0x2c2c5c7c 741104764 esp 0xfbdf6228 0xfbdf6228 ebp 0xfbdf6268 0xfbdf6268 esi 0x23f8f020 603516960 edi 0xfbdf6450 -69245872 eip 0x2407ba53 0x2407ba53 <clang::cxstring::createRef(llvm::StringRef)+83> eflags 0x210206 [ PF IF RF ID ] cs 0x33 51 ss 0x3b 59 ds <unavailable> es <unavailable> fs <unavailable> gs <unavailable>
Comment 31 suggests FFI derails at least in CXString. $ bindgen Segmentation fault (gdb) backtrace #0 0xffffc8c0 in ?? () #1 0x21d00000 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) info registers eax 0xffffc8a8 -14168 ecx 0x22a0e074 580968564 edx 0x1 1 ebx 0xffffc8a8 -14168 esp 0xffffc888 0xffffc888 ebp 0x1ce3920 0x1ce3920 esi 0x22da9690 584750736 edi 0xffffdadc -9508 eip 0xffffc8c0 0xffffc8c0 eflags 0x210286 [ PF SF IF RF ID ] cs 0x33 51 ss 0x3b 59 ds <unavailable> es <unavailable> fs <unavailable> gs <unavailable> or simplified $ cargo new --bin crash_me $ cat <<EOF >crash_me/src/main.rs extern crate clang_sys; use clang_sys::*; fn main() { unsafe { clang_getClangVersion() }; println!("Crash me!"); } EOF $ echo 'clang-sys = "*"' >>crash_me/Cargo.toml $ (cd crash_me; cargo run) Segmentation fault (gdb) bt #0 crash_me::main () at src/main.rs:6 (gdb) info registers eax 0xffffda54 -9644 ecx 0x0 0 edx 0xfffef268 -69016 ebx 0x105dd58 17161560 esp 0xffffda34 0xffffda34 ebp 0xffffda90 0xffffda90 esi 0x0 0 edi 0xffffdafc -9476 eip 0x1005ddd 0x1005ddd <crash_me::main+61> eflags 0x210246 [ PF ZF IF RF ID ] cs 0x33 51 ss 0x3b 59 ds <unavailable> es <unavailable> fs <unavailable> gs <unavailable>
(In reply to Jan Beich from comment #32) > Comment 31 suggests FFI derails at least in CXString. Huh, so I'm out of my depth there, I have no idea why that would crash, mod rustc bug or libclang bug. The definition return value of the FFI function is definitely correct[1]... So not sure what rustc is doing, tbh. I thought of differences with the way clang-sys loads the library, but your test program should use the path that bindgen doesn't use, which means it'd be independent of that... Oh well. [1]: https://github.com/KyleMayes/clang-sys/blob/da6280de7ef5f5e7dde7e63ea00fb6df26eda601/src/lib.rs#L1362
FFI for returning any struct appears to be broken on i386^W i686. Can downstream Rust maintainers reproduce and investigate? $ cat <<EOF >foo.c typedef struct { signed char a; } foo_t; foo_t foo() { foo_t foo; foo.a = 1; return foo; } EOF $ cat <<EOF >foo.rs #[repr(C)] struct foo_t { a: i8, } extern "C" { fn foo() -> foo_t; } fn main() { unsafe { foo() }; println!("Crash me!"); } EOF $ cc -g -shared -o libfoo.so foo.c $ rustc -g -C link-arg=./libfoo.so foo.rs $ ./foo Program received signal SIGSEGV, Segmentation fault. 0x01049f15 in core::fmt::write (output=..., args=...) at src/libcore/fmt/mod.rs:982 982 formatter.buf.write_str(*piece)?; (gdb) backtrace #0 0x01049f15 in core::fmt::write (output=..., args=...) at src/libcore/fmt/mod.rs:982 #1 0x0100a78c in std::io::Write::write_fmt<std::io::stdio::StdoutLock> (self=<optimized out>, fmt=...) at src/libstd/io/mod.rs:1143 #2 std::io::stdio::{{impl}}::write_fmt (self=<optimized out>, args=...) at src/libstd/io/stdio.rs:461 #3 0x0100acb5 in std::io::stdio::print_to<std::io::stdio::Stdout> (label=..., args=..., local_s=<optimized out>, global_s=<optimized out>) at src/libstd/io/stdio.rs:679 #4 std::io::stdio::_print (args=...) at src/libstd/io/stdio.rs:701 #5 0x01005d9e in foo::main () at foo.rs:12 (gdb) info registers eax 0x105bec0 17153728 ecx 0xc0850000 -1065025536 edx 0xffffd9a0 -9824 ebx 0x105cd58 17157464 esp 0xffffd910 0xffffd910 ebp 0xffffd96c 0xffffd96c esi 0x1011e96 16850582 edi 0x161c2878 370944120 eip 0x1049f15 0x1049f15 <core::fmt::write+837> eflags 0x210297 [ CF PF AF SF IF RF ID ] cs 0x33 51 ss 0x3b 59 ds 0x3b 59 es 0x3b 59 fs 0x13 19 gs 0x1b 27 $ rustc --version rustc 1.21.0
Flags: needinfo?(semarie)
Flags: needinfo?(jean-sebastien.pedron)
(In reply to Jan Beich from comment #34) > FFI for returning any struct appears to be broken on i386^W i686. Can > downstream Rust maintainers reproduce and investigate? "returning struct" rings bell on my side. it is something I patched on rustc when porting to i386 in order to respect ABI for OpenBSD. It was https://github.com/rust-lang/rust/blob/master/src/librustc_trans/cabi_x86.rs#L51 the rustc testsuite has several tests for that.
Flags: needinfo?(semarie)
and now I reread some mails from this period, the long version (if I didn't mess myself). Most of OSs using ELF on i386 follows SysV/i386 convention: structures are passed via stack whatever the structure size (Linux and NetBSD cases for example). At least for OpenBSD (but reading tools/clang/lib/CodeGen/TargetInfo.cpp from LLVM/clang, it should be the case also for FreeBSD and DragonflyBSD - see isStructReturnInRegABI function from this file), this convention isn't strictly followed: small structures are passed via registers (if the struct size is small enough to permit it). rustc compiler has special case for that (in src/librustc_trans/cabi_x86.rs file), but only Win32 and MacOS were initially considered. When porting rustc to OpenBSD i386, I adapted rustc to consider also OpenBSD for returning small struct via regiters. So the original problem is a rustc compiler bug: on FreeBSD, when compiling the Rust part, the generated asm code expects struct from stack (it follows SysV/i386 convention); but the C compiler has generated asm code to return it from registers (the other convention, similar to OpenBSD), resulting stack corruption.
Sebastien, thanks! Rust with is_like_openbsd=true + Firefox 57.0b8 + bug 1406952 fix built fine on FreeBSD i386. Landry, can you check mozilla-central or 57.0b9 builds fine with Stylo on OpenBSD i386?
Flags: needinfo?(landry)
Next build of http://buildbot.rhaalovely.net/builders/mozilla-central-i386 and/or http://buildbot.rhaalovely.net/builders/mozilla-beta-i386 should say so, i've removed --disable-stylo from their mozconfigs.
Flags: needinfo?(landry)
Sadly, consumes too much memory: 54:51.66 fatal runtime error: allocator memory exhausted Guess i'll have to try attachment 8916787 [details] [diff] [review] but that wont be commited so what's the point....
Are you building on a 32-bits kernel or a 64-bits kernel with 32-bits userspace (assuming that's a thing on openbsd)?
32-bits everywhere. we don't do such hybrid setups.
(In reply to Landry Breuil (:gaston) from comment #39) > Sadly, consumes too much memory: > > 54:51.66 fatal runtime error: allocator memory exhausted > > Guess i'll have to try attachment 8916787 [details] [diff] [review] but that > wont be commited so what's the point.... If it works we can land it under an env var or what not, would that be useful?
stylo compiled with that (well at least i'm past style, and now in webrender_api/bindings), but that still feels like an ugly workaround :/ If it is necessary for all native builds on 32-bits (whatever the platform), why not detecting it directly in the rust code where your patch is ? i suppose rust has a way to know the architecture of the build host...
(In reply to Landry Breuil (:gaston) from comment #43) > stylo compiled with that (well at least i'm past style, and now in > webrender_api/bindings), but that still feels like an ugly workaround :/ Yay! It certainly is. It's actually less important now that we don't run both release and debug bindings, but anyway... > If it is necessary for all native builds on 32-bits (whatever the platform), why not detecting it directly in the rust code where your patch is ? i suppose rust has a way to know the architecture of the build host... https://github.com/servo/servo/pull/18935 (and yeah, target_pointer_width in a build script is actually host pointer width, fun)
FWIW, I do get a build error from rustc if I force 32-bits processes to be limited to 3GB address space on a 64-bits kernel, but not in stylo build.rs.
Well, guess i spoke too fast, it still failed in the end even with your patch: 70:50.22 Compiling style v0.0.1 (file:///home/landry/src/m-c/servo/components/style) 71:16.68 Compiling style_traits v0.0.1 (file:///home/landry/src/m-c/servo/components/style_traits) 71:20.72 Compiling webrender_bindings v0.1.0 (file:///home/landry/src/m-c/gfx/webrender_bindings) 78:00.87 error: Could not compile `style`. 78:00.90 To learn more, run the command again with --verbose. 78:00.90 gmake[5]: *** [/home/landry/src/m-c/config/rules.mk:1000: force-cargo-library-build] Error 101 78:00.94 gmake[4]: *** [/home/landry/src/m-c/config/recurse.mk:73: toolkit/library/rust/target] Error 2 I have export BUILD_VERBOSE_LOG=1 in .mozconfig but i suppose that's not what sets --verbose for cargo commands ?
(In reply to Landry Breuil (:gaston) from comment #11) > (In reply to Ted Mielczarek [:ted.mielczarek] from comment #10) > > No, this is similar to --enable-debug vs. --enable-debug-symbols. > > MOZ_DEBUG_RUST controls whether we enable debug assertions in Rust code. We > > could change that so setting --disable-debug-symbols would not generate Rust > > debug symbols, which would be reasonable. > > That would definitely work for me. I've filed bug 1409680. Landry, can you try that patch and pass --disable-debug-symbols?
Right, i forgot about that debuginfo bit - fwiw the 'full' (without cfg/target/extern info) build line was: 27:40.59 error: Could not compile `style`. 27:40.59 27:40.60 Caused by: 27:40.61 process didn't exit successfully: `/usr/local/bin/rustc --crate-name style /home/landry/src/m-c/servo/components/style/lib.rs --color always --crate-type lib --emit=dep-info,link -C opt-level=2 -C panic=abort ... --target i686-unknown-openbsd -C linker=/home/landry/src/m-c/build/cargo-linker ...-C debuginfo=2` (signal: 6, SIGABRT: process abort signal) so by default that's with debugging syms. Will try your patch, without emilios to separate things.
Yes the patch from bug 1409680 definitely helps.
Landry, given -Wl,--no-keep-memory isn't enough for Stylo are you planning to add --disable-debug-symbols to OpenBSD i386 buildbot? Is there anything else to do here or should this bug be closed as INVALID or WORKSFORME?
Flags: needinfo?(jean-sebastien.pedron) → needinfo?(landry)
(In reply to Jan Beich from comment #50) > Landry, given -Wl,--no-keep-memory isn't enough for Stylo are you planning > to add --disable-debug-symbols to OpenBSD i386 buildbot? Is there anything > else to do here or should this bug be closed as INVALID or WORKSFORME? Totally forgot, then i remembered it today and added --disable-debug-symbols to the i386 mozconfigs, so now that #1410876 is merged the next builds should be green.
Flags: needinfo?(landry)
http://buildbot.rhaalovely.net/builders/mozilla-beta-i386/builds/169 and http://buildbot.rhaalovely.net/builders/mozilla-central-i386/builds/1067 are now green \o/ Now if only bug 1341234 was fixed ... :)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: