1417798 - stylo: compile with --enable-stylo , force-cargo-libray-build module always error on linux

Status: UNCONFIRMED

(Firefox Build System :: General, defect, P4)

Description

[huangwenjun06]

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36

Steps to reproduce:

Hardware: on x86_64 or MIPS64el.
OS: Centos7 (x86_64) or Fedora21(MIPS64el)
RUST:1.21.0
GCC: 4.9.3

1:download code and compile gecko-dev code  with --enable-stylo.  



Actual results:

2:when build force-cargo-library-build module , both build failed
   either dead loop or bus error.


Expected results:

3:both success.

Comment 1

[huangwenjun06]

Attachment: stylev0.0.1_llvm_compile_error.png

for example: mips64el compile error : style0.0.1 (when i use rust1.21.0 download from rustup.rs)

Comment 2

[huangwenjun06]

Attachment: self_rustc_build_firefox_loop_mips64el.png

for example: when i use rust (compile from rustup.rs code), it dead loop. 
platform: mips64el

Comment 3

[huangwenjun06]

Attachment: offical_rustc_build_firefox_error_mips64el.png

for example: when i use rust (download from rustup.rs), compile style0.0.1 error. 
platform: mips64el

Comment 4

[huangwenjun06]

Attachment: x86_64_compile_firefox_inbound_error.jpg

for example: compile firefox bus error on x86_64.
hardware: x86_64

Comment 5

[huangwenjun06]

someone could give me some suggestion, why I always compile error.

Comment 6

[Chris Peterson [:cpeterson]]

@ Manish, do you recognize these Stylo build errors? Do we support building for mips64el? See the console screenshots.

@ huangwenjun06, have you tried running "./mach bootstrap" in the top of the Firefox source tree recently?

Comment 7

[Manish Goregaokar [:manishearth]]

None of the screenshots contain any of the actual error. Could you upload the full text log?

Comment 8

[huangwenjun06]

Attachment: x86_64_enable_stylo_rust.log

error log info when i build on x86_64

Comment 9

[huangwenjun06]

Attachment: offical_rustc_enable_stylo_build_error_on_mips64el.png

backtrace info about build error when i use offical rustc binary download from rustup.rs.

Comment 10

[huangwenjun06]

Attachment: x86_64_with_offical_rustc_build_stylo_module_compile_error.png

on x86_64, when i use rustc binary download from rustup.rs, the build error info.

Comment 11

[huangwenjun06]

maybe the question like below link? https://github.com/rust-lang/rust/issues/45403
it only support i586-unknown-linux-gnu? and gcc should 5.4.1?

Comment 12

[huangwenjun06]

Attachment: full_build_error_info_mips64el.log

on mips64el , when i use offical rustc download from rustup.rs, the full build log.

on mips64el , when i use rustc that i local build, don't have build log ,just dead loop.

Comment 13

[Manish Goregaokar [:manishearth]]

Error seems to be

> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/cstdio:120:11: error: no member named 'gets' in the global namespace, err: true

and

> /home/loongson/firefox/github/gecko-dev/obj-mips64el-unknown-linux-gnu/dist/include/mozilla/Compiler.h:49:12: fatal error: 'cstddef' file not found


I don't know how to fix this, perhaps your C includes aren't working

Comment 14

[huangwenjun06]

Attachment: rust_sigbus_error_mips64el.log

thanks. 
on x86_64: after i set C_INCLUDE_PATH and CPLUS_INCLUDE_PATH , it now build ok.
but on mips64el: after i set C_INCLUD_PATH,the error info " the 'cstddef' file not found " don't exist . but still have sigbus error.

Comment 15

[huangwenjun06]

Attachment: sigbus_error_bt_info_mips64el.log

the backtrace info for rust on mips64el.

Comment 16

[Makoto Kato [:m_kato] (fever, slow response)]

(In reply to huangwenjun06 from comment #14)
> Created attachment 8930372 [details]
> rust_sigbus_error_mips64el.log
> 
> thanks. 
> on x86_64: after i set C_INCLUDE_PATH and CPLUS_INCLUDE_PATH , it now build
> ok.
> but on mips64el: after i set C_INCLUD_PATH,the error info " the 'cstddef'
> file not found " don't exist . but still have sigbus error.

Most cstddef missing case are that include patch is not enough for clang.

Example, when I use cross build for Linux/aarch64 on Linux/x86_64, we requires the following BINDGEN_CFLAGS in .mozconfig.

export BINDGEN_CFLAGS="--target=aarch64-linux-gnu -I/usr/aarch64-linux-gnu/include/c++/5 -I/usr/lib/llvm-3.9/lib/clang/3.9.1/include"

Comment 17

[huangwenjun06]

thanks,
on mips64el platform ,after i set BINDGEN_CFLAGS, the problem should not the case "cstddef missing", because no error info about something not found, but "signal: 10, SIGBUS: access to undefined memory" error.


error: failed to run custom build command for `style v0.0.1 (file:///home/loongson/firefox/github/gecko-dev/servo/components/style)`
process didn't exit successfully: `/home/loongson/firefox/github/gecko-dev/obj-mips64el-unknown-linux-gnu/toolkit/library/release/build/style-cc804300df307d21/build-script-build` (signal: 10, SIGBUS: access to undefined memory)

Comment 18

[rick]

Same problem here, from amd64-[sun|pc]-solaris2.11 using the [Net|Open]BSD ports tree (thx joyent).

It seems that the build system now unconditionally requires AppleClang (which is the default on the platforms pkgsrc natively supports, or that one temporarily override the C_INCLUDE_PATH and CPLUS_INCLUDE_PATH to clang's default header search path if using GNU CC.

Comment 19

[rick]

which also implies that LLVM and clang be installed as a prerequisite (ports build system takes care of that here)

Comment 20

[rick]

this still leaves system header paths unsatisfied (stddef.h not found), despite /usr/include already in the search paths

Comment 21

[Nathan Froyd [:froydnj]]

Building stylo requires clang/llvm. If bindgen's invocation of clang isn't finding the correct headers, one or more of the following things might be broken:

• an appropriate --target isn't being passed to clang; we pass --target for a non-exhaustive set of os/arch combinations:

https://searchfox.org/mozilla-central/rev/c43240cef5829b8a2dec118faff8a5e1fec6ae1b/build/moz.configure/bindgen.configure#278-347

your combination may not be in there. This is particularly important for cross-compiles, but it probably doesn't hurt for native compiles.

• your clang installation may be broken in some way, since it apparently can't find headers on its own.
• bindgen might not be using the clang that you are using when you compile from the command line.
• you may need to set BINDGEN_CFLAGS in your mozconfig in the event that you have a peculiar standard library setup.
• something else TBD.

We'd need more information to determine which point above you might be running into.