Open Bug 1840554 Opened 1 year ago Updated 1 year ago

C-C TB build fails with /dist/include/mozilla/Assertions.h:367:12: fatal error: 'type_traits' file not found

Tracking

(Not tracked)

Status:

NEW

People

(Reporter: ishikawa, Unassigned)

Details

Attachments

(2 files)

Mysterious download initiated by rust package. 1 year ago ISHIKAWA, Chiaki (deleted), text/plain		Details
a new error and the preceding dump regarding include directories 1 year ago ISHIKAWA, Chiaki (deleted), text/plain		Details

ISHIKAWA, Chiaki

Reporter

Description

•

1 year ago

I am using GCC-12 to build C-C TB under
Debian GNU/Linux.

I needed to patch sources where some compile-time assertions failed. (GCC-12 has more advanced compile-time check. And I enabled GCC to treat many warnings as error to weed out as many problems as possible. )
I could build the binary with M-C/C-C source tree that was several days old. Great!

However, I updated M-C/C-C source tree in the last 24 hours, and now I got the following error and the build cannot build C-C TB debug version.

     Fresh glsl v6.0.2
       Fresh glsl-to-cxx v0.1.0 (/NEW-SSD/NREF-COMM-CENTRAL/mozilla/gfx/wr/glsl-to-cxx)
   Compiling gecko-profiler v0.1.0 (/NEW-SSD/NREF-COMM-CENTRAL/mozilla/tools/profiler/rust-api)
     Running `/NEW-SSD/moz-obj-dir/objdir-tb3/debug/build/gecko-profiler-b98111005b637bdc/build-script-build`
[gecko-profiler 0.1.0] cargo:rerun-if-changed=build.rs
[gecko-profiler 0.1.0] cargo:out_dir=/NEW-SSD/moz-obj-dir/objdir-tb3/x86_64-unknown-linux-gnu/debug/build/gecko-profiler-3c3834564553d4b8/out
[gecko-profiler 0.1.0] cargo:rerun-if-changed=/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla-config.h
[gecko-profiler 0.1.0] cargo:rerun-if-changed=/NEW-SSD/moz-obj-dir/objdir-tb3/tools/profiler/rust-api/extra-bindgen-flags
[gecko-profiler 0.1.0] cargo:rerun-if-changed=/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/GeckoProfiler.h
[gecko-profiler 0.1.0] cargo:rerun-if-changed=/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/ProfilerBindings.h
[gecko-profiler 0.1.0] cargo:rerun-if-env-changed=TARGET
[gecko-profiler 0.1.0] cargo:rerun-if-env-changed=BINDGEN_EXTRA_CLANG_ARGS_x86_64-unknown-linux-gnu
[gecko-profiler 0.1.0] cargo:rerun-if-env-changed=BINDGEN_EXTRA_CLANG_ARGS_x86_64_unknown_linux_gnu
[gecko-profiler 0.1.0] cargo:rerun-if-env-changed=BINDGEN_EXTRA_CLANG_ARGS
[gecko-profiler 0.1.0] /NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/Assertions.h:367:12: fatal error: 'type_traits' file not found
[gecko-profiler 0.1.0] thread 'main' panicked at 'Unable to generate bindings: ClangDiagnostic("/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/Assertions.h:367:12: fatal error: 'type_traits' file not found\n")', tools/profiler/rust-api/build.rs:104:10
[gecko-profiler 0.1.0] stack backtrace:
[gecko-profiler 0.1.0]    0:     0x56277cee7e30 - std::backtrace_rs::backtrace::libunwind::trace::he615646ea344481f
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
[gecko-profiler 0.1.0]    1:     0x56277cee7e30 - std::backtrace_rs::backtrace::trace_unsynchronized::h6ea8eaac68705b9c
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
[gecko-profiler 0.1.0]    2:     0x56277cee7e30 - std::sys_common::backtrace::_print_fmt::h7ac486a935ce0bf7
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:65:5
[gecko-profiler 0.1.0]    3:     0x56277cee7e30 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h1b5a095d3db2e28f
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:44:22
[gecko-profiler 0.1.0]    4:     0x56277cf0daee - core::fmt::write::h445545b92224a1cd
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/fmt/mod.rs:1209:17
[gecko-profiler 0.1.0]    5:     0x56277cee4365 - std::io::Write::write_fmt::h55a43474c6520b00
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/io/mod.rs:1682:15
[gecko-profiler 0.1.0]    6:     0x56277cee7bf5 - std::sys_common::backtrace::_print::h65d20526fdb736b0
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:47:5
[gecko-profiler 0.1.0]    7:     0x56277cee7bf5 - std::sys_common::backtrace::print::h6555fbe12a1cc41b
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:34:9
[gecko-profiler 0.1.0]    8:     0x56277cee947f - std::panicking::default_hook::{{closure}}::hbdf58083140e7ac6
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:267:22
[gecko-profiler 0.1.0]    9:     0x56277cee91ba - std::panicking::default_hook::haef8271c56b74d85
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:286:9
[gecko-profiler 0.1.0]   10:     0x56277cee9bd8 - std::panicking::rust_panic_with_hook::hfd45b6b6c12d9fa5
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:688:13
[gecko-profiler 0.1.0]   11:     0x56277cee9977 - std::panicking::begin_panic_handler::{{closure}}::hf591e8609a75bd4b
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:579:13
[gecko-profiler 0.1.0]   12:     0x56277cee82dc - std::sys_common::backtrace::__rust_end_short_backtrace::h81899558795e4ff7
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:137:18
[gecko-profiler 0.1.0]   13:     0x56277cee9692 - rust_begin_unwind
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:575:5
[gecko-profiler 0.1.0]   14:     0x56277cf0bf83 - core::panicking::panic_fmt::h4235fa9b4675b332
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/panicking.rs:65:14
[gecko-profiler 0.1.0]   15:     0x56277cf0c493 - core::result::unwrap_failed::ha17dbf463031a5e1
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/result.rs:1791:5
[gecko-profiler 0.1.0]   16:     0x56277cb9ca79 - core::result::Result<T,E>::expect::h75ff5232670feae9
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/result.rs:1070:23
[gecko-profiler 0.1.0]   17:     0x56277cb9ca79 - build_script_build::generate_bindings::h8da5a9854d86ba0b
[gecko-profiler 0.1.0]                                at /NEW-SSD/NREF-COMM-CENTRAL/mozilla/tools/profiler/rust-api/build.rs:79:20
[gecko-profiler 0.1.0]   18:     0x56277cb9ca79 - build_script_build::main::h7c44375bb712a71b
[gecko-profiler 0.1.0]                                at /NEW-SSD/NREF-COMM-CENTRAL/mozilla/tools/profiler/rust-api/build.rs:117:5
[gecko-profiler 0.1.0]   19:     0x56277cb9d723 - core::ops::function::FnOnce::call_once::h13c948f98fb41fd3
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/ops/function.rs:251:5
[gecko-profiler 0.1.0]   20:     0x56277cb9d723 - std::sys_common::backtrace::__rust_begin_short_backtrace::haa35bd7fc7cdbed2
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:121:18
[gecko-profiler 0.1.0]   21:     0x56277cb9d6f9 - std::rt::lang_start::{{closure}}::ha182455b736ee2f6
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/rt.rs:166:18
[gecko-profiler 0.1.0]   22:     0x56277cedfafb - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h072eb4cd8da964ba
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/ops/function.rs:286:13
[gecko-profiler 0.1.0]   23:     0x56277cedfafb - std::panicking::try::do_call::h8eca204fe9266946
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:483:40
[gecko-profiler 0.1.0]   24:     0x56277cedfafb - std::panicking::try::h12574e1b7b2cbacb
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:447:19
[gecko-profiler 0.1.0]   25:     0x56277cedfafb - std::panic::catch_unwind::hf71522d4448329d6
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panic.rs:137:14
[gecko-profiler 0.1.0]   26:     0x56277cedfafb - std::rt::lang_start_internal::{{closure}}::h65b66ac9bff580f8
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/rt.rs:148:48
[gecko-profiler 0.1.0]   27:     0x56277cedfafb - std::panicking::try::do_call::hfff61e33ca3db9f1
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:483:40
[gecko-profiler 0.1.0]   28:     0x56277cedfafb - std::panicking::try::he48c8ecead279cad
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:447:19
[gecko-profiler 0.1.0]   29:     0x56277cedfafb - std::panic::catch_unwind::hd510a26bfc950ccc
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panic.rs:137:14
[gecko-profiler 0.1.0]   30:     0x56277cedfafb - std::rt::lang_start_internal::hc680b25eab888da9
[gecko-profiler 0.1.0]                                at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/rt.rs:148:20
[gecko-profiler 0.1.0]   31:     0x56277cb9ce3c - main
[gecko-profiler 0.1.0]   32:     0x7fb8b9b2f18a - __libc_start_call_main
[gecko-profiler 0.1.0]                                at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
[gecko-profiler 0.1.0]   33:     0x7fb8b9b2f245 - __libc_start_main_impl
[gecko-profiler 0.1.0]                                at ./csu/../csu/libc-start.c:381:3
[gecko-profiler 0.1.0]   34:     0x56277cb996f1 - _start
[gecko-profiler 0.1.0]   35:                0x0 - <unknown>
error: failed to run custom build command for `gecko-profiler v0.1.0 (/NEW-SSD/NREF-COMM-CENTRAL/mozilla/tools/profiler/rust-api)`
Caused by:
  process didn't exit successfully: `/NEW-SSD/moz-obj-dir/objdir-tb3/debug/build/gecko-profiler-b98111005b637bdc/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-changed=build.rs
  cargo:out_dir=/NEW-SSD/moz-obj-dir/objdir-tb3/x86_64-unknown-linux-gnu/debug/build/gecko-profiler-3c3834564553d4b8/out
  cargo:rerun-if-changed=/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla-config.h
  cargo:rerun-if-changed=/NEW-SSD/moz-obj-dir/objdir-tb3/tools/profiler/rust-api/extra-bindgen-flags
  cargo:rerun-if-changed=/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/GeckoProfiler.h
  cargo:rerun-if-changed=/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/ProfilerBindings.h
  cargo:rerun-if-env-changed=TARGET
  cargo:rerun-if-env-changed=BINDGEN_EXTRA_CLANG_ARGS_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=BINDGEN_EXTRA_CLANG_ARGS_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=BINDGEN_EXTRA_CLANG_ARGS
  --- stderr
  /NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/Assertions.h:367:12: fatal error: 'type_traits' file not found
  thread 'main' panicked at 'Unable to generate bindings: ClangDiagnostic("/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/Assertions.h:367:12: fatal error: 'type_traits' file not found\n")', tools/profiler/rust-api/build.rs:104:10
  stack backtrace:
     0:     0x56277cee7e30 - std::backtrace_rs::backtrace::libunwind::trace::he615646ea344481f
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
     1:     0x56277cee7e30 - std::backtrace_rs::backtrace::trace_unsynchronized::h6ea8eaac68705b9c
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
     2:     0x56277cee7e30 - std::sys_common::backtrace::_print_fmt::h7ac486a935ce0bf7
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:65:5
     3:     0x56277cee7e30 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h1b5a095d3db2e28f
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:44:22
     4:     0x56277cf0daee - core::fmt::write::h445545b92224a1cd
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/fmt/mod.rs:1209:17
     5:     0x56277cee4365 - std::io::Write::write_fmt::h55a43474c6520b00
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/io/mod.rs:1682:15
     6:     0x56277cee7bf5 - std::sys_common::backtrace::_print::h65d20526fdb736b0
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:47:5
     7:     0x56277cee7bf5 - std::sys_common::backtrace::print::h6555fbe12a1cc41b
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:34:9
     8:     0x56277cee947f - std::panicking::default_hook::{{closure}}::hbdf58083140e7ac6
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:267:22
     9:     0x56277cee91ba - std::panicking::default_hook::haef8271c56b74d85
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:286:9
    10:     0x56277cee9bd8 - std::panicking::rust_panic_with_hook::hfd45b6b6c12d9fa5
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:688:13
    11:     0x56277cee9977 - std::panicking::begin_panic_handler::{{closure}}::hf591e8609a75bd4b
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:579:13
    12:     0x56277cee82dc - std::sys_common::backtrace::__rust_end_short_backtrace::h81899558795e4ff7
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:137:18
    13:     0x56277cee9692 - rust_begin_unwind
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:575:5
    14:     0x56277cf0bf83 - core::panicking::panic_fmt::h4235fa9b4675b332
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/panicking.rs:65:14
    15:     0x56277cf0c493 - core::result::unwrap_failed::ha17dbf463031a5e1
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/result.rs:1791:5
    16:     0x56277cb9ca79 - core::result::Result<T,E>::expect::h75ff5232670feae9
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/result.rs:1070:23
    17:     0x56277cb9ca79 - build_script_build::generate_bindings::h8da5a9854d86ba0b
                                 at /NEW-SSD/NREF-COMM-CENTRAL/mozilla/tools/profiler/rust-api/build.rs:79:20
    18:     0x56277cb9ca79 - build_script_build::main::h7c44375bb712a71b
                                 at /NEW-SSD/NREF-COMM-CENTRAL/mozilla/tools/profiler/rust-api/build.rs:117:5
    19:     0x56277cb9d723 - core::ops::function::FnOnce::call_once::h13c948f98fb41fd3
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/ops/function.rs:251:5
    20:     0x56277cb9d723 - std::sys_common::backtrace::__rust_begin_short_backtrace::haa35bd7fc7cdbed2
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:121:18
    21:     0x56277cb9d6f9 - std::rt::lang_start::{{closure}}::ha182455b736ee2f6
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/rt.rs:166:18
    22:     0x56277cedfafb - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h072eb4cd8da964ba
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/ops/function.rs:286:13
    23:     0x56277cedfafb - std::panicking::try::do_call::h8eca204fe9266946
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:483:40
    24:     0x56277cedfafb - std::panicking::try::h12574e1b7b2cbacb
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:447:19
    25:     0x56277cedfafb - std::panic::catch_unwind::hf71522d4448329d6
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panic.rs:137:14
    26:     0x56277cedfafb - std::rt::lang_start_internal::{{closure}}::h65b66ac9bff580f8
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/rt.rs:148:48
    27:     0x56277cedfafb - std::panicking::try::do_call::hfff61e33ca3db9f1
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:483:40
    28:     0x56277cedfafb - std::panicking::try::he48c8ecead279cad
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:447:19
    29:     0x56277cedfafb - std::panic::catch_unwind::hd510a26bfc950ccc
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panic.rs:137:14
    30:     0x56277cedfafb - std::rt::lang_start_internal::hc680b25eab888da9
                                 at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/rt.rs:148:20
    31:     0x56277cb9ce3c - main
    32:     0x7fb8b9b2f18a - __libc_start_call_main
                                 at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    33:     0x7fb8b9b2f245 - __libc_start_main_impl
                                 at ./csu/../csu/libc-start.c:381:3
    34:     0x56277cb996f1 - _start
    35:                0x0 - <unknown>
gmake[4]: *** [/NEW-SSD/NREF-COMM-CENTRAL/mozilla/config/makefiles/rust.mk:440: force-cargo-library-build] Error 101
gmake[4]: Leaving directory '/NEW-SSD/moz-obj-dir/objdir-tb3/toolkit/library/rust'
gmake[3]: *** [/NEW-SSD/NREF-COMM-CENTRAL/mozilla/config/recurse.mk:72: toolkit/library/rust/target] Error 2
gmake[3]: *** Waiting for unfinished jobs....
gmake[4]: Leaving directory '/NEW-SSD/moz-obj-dir/objdir-tb3/dom/commandhandler'
gmake[4]: Leaving directory '/NEW-SSD/moz-obj-dir/objdir-tb3/dom/credentialmanagement'
In file included from /NEW-SSD/NREF-COMM-CENTRAL/mozilla/dom

I am using --without-sysroot to configure the build environment.

The obvious reason for the failure is the missing "type_trait" file in the include path.

|locate type_traits|> on my PC shows that I do have |type_traits| for gcc-12 (as well as gcc-10, gcc-11 and gcc-8).

I searched for |type_traits| in bugzilla and found the following entries.
Bug 900040
Bug 1341500
They are not relevant here since rust compiler seems unable to locate the type_traits file in the first place.

Something has changed in the last few days since I could build with the old M-C/C-C tree and not with the latest tree.

ISHIKAWA, Chiaki

Reporter

Comment 1

•

1 year ago

I am using GCC-12 to build C-C TB.

Why does this symbol ClangDiagnostic() appears in the error message.
That might explain the issue.

[gecko-profiler 0.1.0] thread 'main' panicked at 'Unable to generate bindings: ClangDiagnostic("/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/Assertions.h:367:12: fatal error: 'type_traits' file not found\n")', tools/profiler/rust-api/build.rs:104:10

ISHIKAWA, Chiaki

Reporter

Comment 2

•

1 year ago

Can this post in other software project relevant here?

[libgpiod][bug] building rust bindings requires clang headers
https://www.spinics.net/lists/linux-gpio/msg86930.html

Given the strange |ClangDiagnostic|, it may be so.

ISHIKAWA, Chiaki

Reporter

Comment 3

•

1 year ago

Attached file Mysterious download initiated by rust package. (deleted) — Details

Egad.

I am using Debian GNU/Linux.

There could have been mismatches between the packages installed by
Debian and bootstrapped by |mach|.

Trying to figure out where this header is searched (not knowing exactly which syscalls to trace) I invoked the library build command with |strace -o /tmp/t.out|, it failed, but somehow this time around (about after 17:00 JST June 28), the failure is followed by a series of automatic download of packages (!?)


Caused by:
  process didn't exit successfully: `CARGO=/home/ishikawa/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo CARGO_CRATE_NAME=build_script_build CARGO_MANIFEST_DIR=/NEW-SSD/NREF-COMM-CENTRAL/mozilla/third_party/rust/proc-macro2 CARGO_PKG_AUTHORS='David Tolnay <dtolnay@gmail.com>:Alex Crichton <alex@alexcrichton.com>' CARGO_PKG_DESCRIPTION='A substitute implementation of the compiler'\''s `proc_macro` API to decouple token-based libraries from the procedural macro use case.' CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE='MIT OR Apache-2.0' CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=proc-macro2 CARGO_PKG_REPOSITORY='https://github.com/dtolnay/proc-macro2' CARGO_PKG_RUST_VERSION=1.31 CARGO_PKG_VERSION=1.0.59 CARGO_PKG_VERSION_MAJOR=1 CARGO_PKG_VERSION_MINOR=0 CARGO_PKG_VERSION_PATCH=59 CARGO_PKG_VERSION_PRE='' LD_LIBRARY_PATH='/NEW-SSD/NREF-COMM-CENTRAL/mozilla/target/debug/deps:/home/ishikawa/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib::/usr/local/lib:/usr/local/lib' rustc --crate-name build_script_build --edition=2018 /NEW-SSD/NREF-COMM-CENTRAL/mozilla/third_party/rust/proc-macro2/build.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C opt-level=1 -C embed-bitcode=no -C debuginfo=2 -C debug-assertions=on --cfg 'feature="default"' --cfg 'feature="proc-macro"' -C metadata=34c03ef62840545f -C extra-filename=-34c03ef62840545f --out-dir /NEW-SSD/NREF-COMM-CENTRAL/mozilla/target/debug/build/proc-macro2-34c03ef62840545f -L dependency=/NEW-SSD/NREF-COMM-CENTRAL/mozilla/target/debug/deps --cap-lints warn` (exit status: 1)
warning: build failed, waiting for other jobs to finish...
info: downloading component 'clippy'
info: downloading component 'rust-docs'
info: downloading component 'rust-std'
info: downloading component 'rustc'
info: downloading component 'rustfmt'
info: removing previous version of component 'cargo'
info: removing previous version of component 'clippy'
info: removing previous version of component 'rust-docs'
info: removing previous version of component 'rust-std'
info: removing previous version of component 'rustc'
info: removing previous version of component 'rustfmt'
info: installing component 'rust-src'
info: installing component 'cargo'
info: installing component 'clippy'
info: installing component 'rust-docs'
info: installing component 'rust-std'
info: installing component 'rustc'
info: installing component 'rustfmt'
ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$ ./do-make-tb.sh

Full log is attached.

I am trying to see if these spontaneous updates fix the issue at hand.

ISHIKAWA, Chiaki

Reporter

Comment 4

•

1 year ago

No, I still get the same error at the end of |mach build|.

  --- stderr
  /NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/Assertions.h:367:12: fatal error: 'type_traits' file not found
  thread 'main' panicked at 'Unable to generate bindings: ClangDiagnostic("/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/Assertions.h:367:12: fatal error: 'type_traits' file not found\n")', tools/profiler/rust-api/build.rs:104:10
  stack backtrace:
     0:     0x5628e60c474a - std::backtrace_rs::backtrace::libunwind::trace::h9a6b80bbf328ba5d
                                 at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
     1:     0x5628e60c474a - std::backtrace_rs::backtrace::trace_unsynchronized::hd

ISHIKAWA, Chiaki

Reporter

Comment 5

•

1 year ago

In the attached log, I see the following.

info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
.,. [omission]...upd
warning: Signature verification failed for 'https://static.rust-lang.org/dist/channel-rust-stable.toml'
warning: Signature verification failed for 'https://static.rust-lang.org/dist/channel-rust-stable.toml'
info: latest update on 2023-06-01, rust version 1.70.0 (90c541806 2023-05-31)
info: latest update on 2023-06-01, rust version 1.70.0 (90c541806 2023-05-31)

Previously, it was 1.6.something.

I am afraid there is a certain stability issues on Debian GNU/Linux.
I wonder why not many people who are testing locally are hit by this.
I suspect that Debian users are in minority, and people using GCC to compile C-C TB is still rarer.

I should do clobber and re>configure and see if things improve.
Well, no improvement.

I think my trying to run the rust library build did not have proper environmental variable settings, come to think of it, since I simply copied the
command from a failed log.

I wonder if there is a way to explicitly pass an additional search path for C/C++ header files to rustc command that invokes CARGO creation.
That has been taken care of before by the build process up to the last source update. Hmm...

ISHIKAWA, Chiaki

Reporter

Comment 6

•

1 year ago

Attached file a new error and the preceding dump regarding include directories (deleted) — Details

I now realize that after the spontaneous update of rustc and clobber,configure, build produces new set of errors.
I upload the excerpt from the local log.
It contains detailed information about include directories (?) and so many someone in the know can figure out what is causing the issue.
In this instance, the error is

[neqo-crypto 0.6.4] /NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/nss/mozpkix/pkixtypes.h:28:10: fatal error: 'memory' file not found
[neqo-crypto 0.6.4] thread 'main' panicked at 'unable to generate bindings: ClangDiagnostic("/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/nss/mozpkix/pkixtypes.h:28:10: fatal error: 'memory' file not found\n")', /NEW-SSD/NREF-COMM-CENTRAL/mozilla/third_party/rust/neqo-crypto/build.rs:282:39

Looking at the output of |locate memory | grep 'memory$' |, I think one of the following ought to be included, i.e., found but not found the build process.

...
/home/ishikawa/.mozbuild/sysroot/usr/include/c++/4.9/memory
/home/ishikawa/.mozbuild/sysroot/usr/include/c++/4.9/ext/memory
/home/ishikawa/.mozbuild/sysroot/usr/include/c++/4.9/tr1/memory
/home/ishikawa/.mozbuild/sysroot-wasm32-wasi/include/c++/v1/__memory
/home/ishikawa/.mozbuild/sysroot-wasm32-wasi/include/c++/v1/memory
/home/ishikawa/.mozbuild/sysroot-wasm32-wasi/include/c++/v1/experimental/__memory
/home/ishikawa/.mozbuild/sysroot-x86_64-linux-gnu/usr/include/c++/8/memory
/home/ishikawa/.mozbuild/sysroot-x86_64-linux-gnu/usr/include/c++/8/experimental/memory
/home/ishikawa/.mozbuild/sysroot-x86_64-linux-gnu/usr/include/c++/8/ext/memory
/home/ishikawa/.mozbuild/sysroot-x86_64-linux-gnu/usr/include/c++/8/tr1/memory
/home/ishikawa/.mozbuild/wasi-sysroot/share/wasi-sysroot/include/c++/v1/__memory
/home/ishikawa/.mozbuild/wasi-sysroot/share/wasi-sysroot/include/c++/v1/memory
/home/ishikawa/.mozbuild/wasi-sysroot/share/wasi-sysroot/include/c++/v1/experimental/__memory
/home/ishikawa/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/share/doc/rust/html/core/core_arch/wasm32/memory
        ...
/usr/include/boost/compute/memory
/usr/include/boost/thread/csbl/memory
/usr/include/c++/10/memory
/usr/include/c++/10/experimental/memory
/usr/include/c++/10/ext/memory
/usr/include/c++/10/tr1/memory
/usr/include/c++/11/memory
/usr/include/c++/11/experimental/memory
/usr/include/c++/11/ext/memory
/usr/include/c++/11/tr1/memory
/usr/include/c++/12/memory
/usr/include/c++/12/experimental/memory
/usr/include/c++/12/ext/memory
/usr/include/c++/12/tr1/memory
/usr/include/c++/8/memory
/usr/include/c++/8/experimental/memory
/usr/include/c++/8/ext/memory
/usr/include/c++/8/tr1/memory
/usr/src/linux-headers-5.17.0-1-common/include/memory
/usr/src/linux-headers-5.17.0-1-common/include/dt-bindings/memory
/usr/src/linux-headers-5.18.0-2-common/include/memory
/usr/src/linux-headers-5.18.0-2-common/include/dt-bindings/memory
/usr/src/linux-headers-6.0.0-2-common/include/memory
/usr/src/linux-headers-6.0.0-2-common/include/dt-bindings/memory

I will wait for another day or so before I update the source to figure out the root cause.

ISHIKAWA, Chiaki

Reporter

Comment 7

•

1 year ago

This may be a smoking gun：
Please recall I am trying to compile C-C TB with GCC-12, and the build succeeded a couple of days ago with source tree M-C/C-C.
I do update Debian packages rather regularly.

[neqo-crypto 0.6.4] InstalledDir:
[neqo-crypto 0.6.4] Found candidate GCC installation: /../lib/gcc/x86_64-linux-gnu/10
[neqo-crypto 0.6.4] Found candidate GCC installation: /../lib/gcc/x86_64-linux-gnu/11
[neqo-crypto 0.6.4] Found candidate GCC installation: /../lib/gcc/x86_64-linux-gnu/12
[neqo-crypto 0.6.4] Found candidate GCC installation: /../lib/gcc/x86_64-linux-gnu/13
[neqo-crypto 0.6.4] Found candidate GCC installation: /../lib/gcc/x86_64-linux-gnu/7
[neqo-crypto 0.6.4] Found candidate GCC installation: /../lib/gcc/x86_64-linux-gnu/7.5.0
[neqo-crypto 0.6.4] Found candidate GCC installation: /../lib/gcc/x86_64-linux-gnu/8
[neqo-crypto 0.6.4] Found candidate GCC installation: /../lib/gcc/x86_64-linux-gnu/9
[neqo-crypto 0.6.4] Selected GCC installation: /../lib/gcc/x86_64-linux-gnu/13     <---- WHAT?  I did not even have gcc-13 (!?)

That is, somehow, there seem to be an errant binary or installation header meant for GCC 13, which misguided the generation of C/C++ binding generation?
I have NOT installed gcc-13 as far as I could tell and thus the headers for 13 may not be complete.
This is very likely Debian issue, but I wished the lib and/or headers for gcc-12 is picked up since I AM using gcc-12.

Now, I have EXPLICITLY installed gcc-13 since I think it finally became available in Debian since the day before or so.
I have tried to upgrade to gcc-13, but it has not been available even in the testing repository for quite a while. But now it is available.
I am hoping this will solve the issue.
No wait, even if it builds, it uses GCC-12 and uses GCC-13 headers/libraries? That does not sound good.

Anyway, I will report the result of build.

ISHIKAWA, Chiaki

Reporter

Comment 8

•

1 year ago

The build itself succeeded after I installed GCC-13 and related libstdc++ .

sudo apt-get install gcc-13 g++-13
[sudo] password for ishikawa: 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following package was automatically installed and is no longer required:
  libmujs2
Use 'sudo apt autoremove' to remove it.
The following additional packages will be installed:
  cpp-13 libstdc++-13-dev
Suggested packages:
  gcc-13-locales cpp-13-doc g++-13-multilib gcc-13-doc gcc-13-multilib libstdc++-13-doc
The following NEW packages will be installed:
  cpp-13 g++-13 gcc-13 libstdc++-13-dev
0 upgraded, 4 newly installed, 0 to remove and 39 not upgraded.
Need to get 178 MB of archives.
After this operation, 609 MB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://debian-mirror.sakura.ne.jp/debian testing/main amd64 cpp-13 amd64 13.1.0-6 [54.4 MB]
Get:2 http://debian-mirror.sakura.ne.jp/debian testing/main amd64 gcc-13 amd64 13.1.0-6 [62.8 MB]
Get:3 http://debian-mirror.sakura.ne.jp/debian testing/main amd64 libstdc++-13-dev amd64 13.1.0-6 [2,217 kB]
Get:4 http://debian-mirror.sakura.ne.jp/debian testing/main amd64 g++-13 amd64 13.1.0-6 [58.7 MB]
Fetched 178 MB in 12s (14.4 MB/s)
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
Selecting previously unselected package cpp-13.
(Reading database ... 622230 files and directories currently installed.)
Preparing to unpack .../cpp-13_13.1.0-6_amd64.deb ...
Unpacking cpp-13 (13.1.0-6) ...
Selecting previously unselected package gcc-13.
Preparing to unpack .../gcc-13_13.1.0-6_amd64.deb ...
Unpacking gcc-13 (13.1.0-6) ...
Selecting previously unselected package libstdc++-13-dev:amd64.
Preparing to unpack .../libstdc++-13-dev_13.1.0-6_amd64.deb ...
Unpacking libstdc++-13-dev:amd64 (13.1.0-6) ...
Selecting previously unselected package g++-13.
Preparing to unpack .../g++-13_13.1.0-6_amd64.deb ...
Unpacking g++-13 (13.1.0-6) ...
Setting up cpp-13 (13.1.0-6) ...
Setting up gcc-13 (13.1.0-6) ...
Setting up libstdc++-13-dev:amd64 (13.1.0-6) ...
Setting up g++-13 (13.1.0-6) ...
Processing triggers for man-db (2.11.2-2) ...
Processing triggers for ccache (4.8+really4.7.5-1) ...
Updating symlinks in /usr/lib/ccache ...
ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$ gcc-13 --version
gcc-13 (Debian 13.1.0-6) 13.1.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

My observation is that some packages in Debian packaging system or something created the
directory for

[neqo-crypto 0.6.4] Selected GCC installation: /../lib/gcc/x86_64-linux-gnu/13 <---- WHAT? I did not even have gcc-13 (!?)

that misled cbindgen or some program similar to this to pickup the not so fully populated GCC-13 header/lib.

Q-1: But I am not sure if the binary runs because, if I am not mistaken, it is compiled using GCC-12 but somehow uses headers meant for GCC-13 to generate C/C++ headers?
Or this process only generates C/C++ headers, which are not used during the build?

Q-2: I regularly created C-C TB binary using GCC-11 after I installed GCC-12.
I wonder, then, if the binary I created locally used GCC-12 header for creating rust bindings even when I use GCC-11?

Q-3: Not a question, but rather a wish.
If cbindgen can figure out I am using GCC-12 by looking at CC or CXX environment variable, why doesn't it pick up the installed directory for GCC-12 instead of the highest numbered directory for 13 to create rust binding header files?

Inquiring mind wants to know.

I can now see this part of build is very brittle and not robust to environment changes of individual users.
In my case, I had no way to control it because I suspect the packaging system did something funny during the transition to GCC-13 (which seems to have hit the testing repository only in the last couple of days.).

Now I am going to try the build using GCC-13 instead of GCC-12 now that I installed GCC-13.
There were some strange compile-time issues with GCC-12 that I had to manually handle by disabling some warnings for several files by removing the warning option on the command line. They may be related to the strange mixture of GCC-13 header directory (at least partically filled???)

I will keep you posted.

ISHIKAWA, Chiaki

Reporter

Comment 9

•

1 year ago

It looks I could build C-C TB with GCC0-13 after proper source modifications where compile-time issues were reported.

However, the question remain that if I try to use the previous version of GCC, such as GCC-11, does cbindgen (I presume this is the tool to generate the headers for/from rust) properly use the headers for GCC-11 to generate them instead of picking up the highest numbered header directory for GCC-13?

ISHIKAWA, Chiaki

Reporter

Comment 10

•

1 year ago

Well, build again fails after I upgraded M-C/C-C tree with different issues.
I think the build infra is going through a bit of change and some local build environments are not catching up.

Suddenly during configure, the linker command option "-Wl,-z,pack-relative-relocs" seems to added afresh.

Problem is that I had been using gnu-gold linker since it is faster than stock ld, but gnu-gold linker does not grok this opti0on, pack-relative-relocs.
So I had to explicitly state that GCC-13, G++13 use |mold| linker, which is fast and groks this option by specifying -fuse-ld=mold in CXXFLAGS and CFLAGS environment variables.
This seems to solve the issue.

However, during the subsequent build stage, I get the following error. I think this is from rust compilation (?).


     Running `/NEW-SSD/moz-obj-dir/objdir-tb3/debug/build/proc-macro2-e3b5db6a6f3cfc11/build-script-build`
[proc-macro2 1.0.59] /NEW-SSD/moz-obj-dir/objdir-tb3/debug/build/proc-macro2-e3b5db6a6f3cfc11/build-script-build: error while loading shared libraries: /NEW-SSD/moz-obj-dir/objdir-tb3/debug/build/proc-macro2-e3b5db6a6f3cfc11/build-script-build: DT_RELR without GLIBC_ABI_DT_RELR dependency
error: failed to run custom build command for `proc-macro2 v1.0.59`
Caused by:
  process didn't exit successfully: `/NEW-SSD/moz-obj-dir/objdir-tb3/debug/build/proc-macro2-e3b5db6a6f3cfc11/build-script-build` (exit status: 127)
  --- stderr
  /NEW-SSD/moz-obj-dir/objdir-tb3/debug/build/proc-macro2-e3b5db6a6f3cfc11/build-script-build: error while loading shared libraries: /NEW-SSD/moz-obj-dir/objdir-tb3/debug/build/proc-macro2-e3b5db6a6f3cfc11/build-script-build: DT_RELR without GLIBC_ABI_DT_RELR dependency
gmake[4]: *** [/NEW-SSD/NREF-COMM-CENTRAL/mozilla/config/makefiles/rust.mk:440: force-cargo-library-build] Error 101
gmake[4]: Leaving directory '/NEW-SSD/moz-obj-dir/objdir-tb3/toolkit/library/rust'
gmake[3]: *** [/NEW-SSD/NREF-COMM-CENTRAL/mozilla/config/recurse.mk:72: toolkit/library/rust/target] Error 2
gmake[3]: *** Waiting for unfinished jobs....

I am not sure if this is the packaging issue of Debian or rust-related issue for now.

I will dig a bit more.

ISHIKAWA, Chiaki

Reporter

Comment 11

•

1 year ago

Ok, the command that failed was produced immediately before the error. So that build was buggy.

   Compiling proc-macro2 v1.0.59
     Running `CARGO=/home/ishikawa/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo CARGO_CRATE_NAME=build_script_build CARGO_MANIFEST_DIR=/NEW-SSD/NREF-COMM-CENTRAL/mozilla/third_party/rust/proc-macro2 CARGO_PKG_AUTHORS='David Tolnay <dtolnay@gmail.com>:Alex Crichton <alex@alexcrichton.com>' CARGO_PKG_DESCRIPTION='A substitute implementation of the compiler'\''s `proc_macro` API to decouple token-based libraries from the procedural macro use case.' CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE='MIT OR Apache-2.0' CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=proc-macro2 CARGO_PKG_README=README.md CARGO_PKG_REPOSITORY='https://github.com/dtolnay/proc-macro2' CARGO_PKG_RUST_VERSION=1.31 CARGO_PKG_VERSION=1.0.59 CARGO_PKG_VERSION_MAJOR=1 CARGO_PKG_VERSION_MINOR=0 CARGO_PKG_VERSION_PATCH=59 CARGO_PKG_VERSION_PRE='' LD_LIBRARY_PATH='/NEW-SSD/moz-obj-dir/objdir-tb3/debug/deps:/home/ishikawa/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib::/usr/local/lib:/usr/local/lib' sccache /home/ishikawa/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc --crate-name build_script_build --edition=2018 /NEW-SSD/NREF-COMM-CENTRAL/mozilla/third_party/rust/proc-macro2/build.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C opt-level=1 -C embed-bitcode=no -C debuginfo=2 -C debug-assertions=on --cfg 'feature="default"' --cfg 'feature="proc-macro"' -C metadata=e3b5db6a6f3cfc11 -C extra-filename=-e3b5db6a6f3cfc11 --out-dir /NEW-SSD/moz-obj-dir/objdir-tb3/debug/build/proc-macro2-e3b5db6a6f3cfc11 -C linker=/NEW-SSD/NREF-COMM-CENTRAL/mozilla/build/cargo-linker -L dependency=/NEW-SSD/moz-obj-dir/objdir-tb3/debug/deps --cap-lints warn`

ISHIKAWA, Chiaki

Reporter

Comment 12

•

1 year ago

/NEW-SSD/moz-obj-dir/objdir-tb3/debug/build/proc-macro2-e3b5db6a6f3cfc11/build-script-build: error while loading shared libraries: /NEW-SSD/moz-obj-dir/objdir-tb3/debug/build/proc-macro2-e3b5db6a6f3cfc11/build-script-build: DT_RELR without GLIBC_ABI_DT_RELR dependency

I think some libraries linked don't have support for DT_RELR.
See the discussion.
https://sourceware.org/bugzilla/show_bug.cgi?id=27923

But when did this change happen?
On all linux platforms?
Debian is rather conservative and often slow adopting new features.
Yet, the following debian bug tracker mentions that it now has glibc that supports this feature.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996598

Still investigating...

ISHIKAWA, Chiaki

Reporter

Comment 13

•

1 year ago

My findings so far. It reflects the brittleness of the build process caused by subtle variation of tools involved.

I have used three different linkers in a somewhat mixed manner.
ld
ld.gold
mold

I have not been using llvm-ld simply because I have been using GCC.

Each of these linkers have different characteristics in terms of functionality.

link speed.
support for packed relative addressing with |-z pack-relative-relocs|
See https://maskray.me/blog/2021-10-31-relative-relocations-and-relr for general discussion of this feature and how it is implemented by various tools including the linkers.

Whether each of the linkers accepts this argument, and
if the support is functional is another matter.

I THINK mold now accepts the |--z pack-relative-relocs f| argument but it does not support it correctly.
See mold bug reports/issues.
https://github.com/rui314/mold/issues/653 <-- mold is not interested in supporting the feature.

https://github.com/rui314/mold/releases
"mold now accepts -z nopack-relative-relocs as an alias for --pack-dyn-relocs=none for the sake of compatibility with GNU linkers. (b510588)"
Accepting this option, but not implementing the feature may be the reason for the build failure as I explain below when I use mold for the main linker during |mach configure|.

(I assume mold has been updated very lately as part of Debian GNU/Linux package upgrade in the last couple of weeks.)

Before:
I used to use mold as |ld| by creating a shell script called "ld" which actually invokes "mold" in my PATH.
I think the latest "mold" accepts --pack-dyn-relocs and thus |mach configure| results in the use of |-z pack-relative-relocs|
during build.
Unfortunately, this is my pure guess, but there do seem to be libraries that are not compatible with this feature, or mold creates an incorrect binary when it is passed with 1.11.0 (the version on my computer now.) This is a conjecture. Anything goes in this scenario.

After: I now see there seem to be support issue of |-z pack-relative-relocs| with my binary toolchain.
So I use ld.gold which DOES NOT support |-z pack-relative-relocs| as ld during |mach configure|.
I do this by making by |ld| script in my PATH to invoke ld.gold.
Now that the configured build does NOT use this option, either ld.gold or mold can be used for speedier link than ld.
I specify -fuse-ld=mold as part of CFLAGS, and CXXFLAGS.
This makes the linking of libxul rather fast.
On the other hand, the previous error suggested

NEW-SSD/moz-obj-dir/objdir-tb3/debug/build/proc-macro2-e3b5db6a6f3cfc11/build-script-build:
was linkked incorrectly when |-z pack-relative-relocs| was specified. I suspect the linker used by CARGO-LINKER was to blame.
But I am not entirely sure what linker was used. Was it |ld| in my PATH or does CARGO-LINKER use a different ld on its own?
I don't know.
But reading the shell script CARGO-LINKER, I now specify the environment variables as follows.

export MOZ_CARGO_WRAP_LD=/usr/bin/mold
export MOZ_CARGO_WRAP_LD_CXX=/usr/bin/mold

I hope this uses mold for linking rust programs and libraries.
But I am not so sure.

Anyway with the following setup, I seem to have created a working C-C TB binary.

ld in my PATH invokes ld.gold,
mold is used for gcc-13/g++-13 linking, and
possibly for CARGO-LINKER (but I have no way of verifying the last point).

I will monitor a few more days after updating M-C/C-C daily and
also trying to downgrade gcc-13 to gcc-11 and see
if the build still works.
The last point is related to "I wished the lib and/or headers for gcc-11 is picked up since I AM using gcc-11 even though the headers/libraries for gcc-12 and gcc-13 are installed."

The cbindgen issues and this strange mismatches of libraries at run-time or broken binary, "DT_RELR without GLIBC_ABI_DT_RELR dependency" (intentionally done to break the execution since otherwise mysterious things appear) are abundant on the Internet.

I hope this bugzilla can be kept open for a while until the build tools become more bug-free and stabilize.

ISHIKAWA, Chiaki

Reporter

Comment 14

•

1 year ago

The original issue was that cbindgen (I think) chose incompletely installed headers/libries for gcc-13 while I was trying to use gcc-11.

Subsequently, I installed gcc-13 which only became available while I was having the issues, and THAT original problem of missing header file was solved.
I found out that somehow the cbindgen(?) tries to use highest numbered header directory even if that was not completely populated during package transition of Debian GNU/Linux.

However, when I tried to use gcc-11 for build while I have gcc-12 and gcc-13 are installed
rust-part of build seemed to pick up gcc-13 headers(?) for creating c/c++ binding files (or vice versa).
This could be a dormant problem.
Below is the excerpt from the build which now I use gcc-11 (not gcc-13) for configure/build.
Note the line with a comment "****".

[nss-gk-api 0.2.1] clang version 16.0.4 (taskcluster-ZwFgqWoxS7-1Fnmpg-wL5w)
[nss-gk-api 0.2.1] Target: x86_64-unknown-linux-gnu
[nss-gk-api 0.2.1] Thread model: posix
[nss-gk-api 0.2.1] InstalledDir:
[nss-gk-api 0.2.1] Found candidate GCC installation: /../lib/gcc/x86_64-linux-gnu/10
[nss-gk-api 0.2.1] Found candidate GCC installation: /../lib/gcc/x86_64-linux-gnu/11
[nss-gk-api 0.2.1] Found candidate GCC installation: /../lib/gcc/x86_64-linux-gnu/12
[nss-gk-api 0.2.1] Found candidate GCC installation: /../lib/gcc/x86_64-linux-gnu/13
[nss-gk-api 0.2.1] Found candidate GCC installation: /../lib/gcc/x86_64-linux-gnu/7
[nss-gk-api 0.2.1] Found candidate GCC installation: /../lib/gcc/x86_64-linux-gnu/7.5.0
[nss-gk-api 0.2.1] Found candidate GCC installation: /../lib/gcc/x86_64-linux-gnu/8
[nss-gk-api 0.2.1] Found candidate GCC installation: /../lib/gcc/x86_64-linux-gnu/9
[nss-gk-api 0.2.1] Selected GCC installation: /../lib/gcc/x86_64-linux-gnu/13b   <----- *****  13 is chosen ******
[nss-gk-api 0.2.1] Candidate multilib: .;@m64
[nss-gk-api 0.2.1] Selected multilib: .;@m64
[nss-gk-api 0.2.1] ignoring nonexistent directory "lib/clang/16/include"
[nss-gk-api 0.2.1] ignoring nonexistent directory "/../lib/gcc/x86_64-linux-gnu/13/../../../../x86_64-linux-gnu/include"
[nss-gk-api 0.2.1] ignoring nonexistent directory "/include"
[nss-gk-api 0.2.1] ignoring duplicate directory "/usr/lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13"
[nss-gk-api 0.2.1] ignoring duplicate directory "/usr/lib/gcc/x86_64-linux-gnu/13/../../../../include/x86_64-linux-gnu/c++/13"
[nss-gk-api 0.2.1] ignoring duplicate directory "/usr/lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/backward"
[nss-gk-api 0.2.1] ignoring duplicate directory "/usr/local/include"
[nss-gk-api 0.2.1] ignoring duplicate directory "/usr/include/x86_64-linux-gnu"
[nss-gk-api 0.2.1] ignoring duplicate directory "/usr/include"

This behavior may make it hard to create a binary by selecting a non-highest-numbered compiler version when
there are multiple compiler versions installed as in my case.

I have no idea if this is a desired behavior for rust binding generaion.

ISHIKAWA, Chiaki

Reporter

Comment 15

•

1 year ago

For the undesirable cbindgen behavior, I filed an issue at
https://github.com/mozilla/cbindgen/issues/854

I would think, maybe an environment variable
CBINDGEN_CC or something like that can lead the proper choice.
If CBINDGEN_CC is not defined, the trditional behavior is used.
CBINDGEN_CC is set, say, to "gcc-11", the header directory is searched intelligently.
I found it rather odd that cbindgen during build process did seem to understand that I was using GCC instead of CLANG.
So there must be a mechanism to tell cbindgen the compiler being used for C-C TB build, at least.

You need to log in before you can comment on or make changes to this bug.

Bugzilla

Quick Search

C-C TB build fails with /dist/include/mozilla/Assertions.h:367:12: fatal error: 'type_traits' file not found

Categories

(MailNews Core :: Build Config, defect)

Tracking

(Not tracked)

People

(Reporter: ishikawa, Unassigned)

References

Details

Crash Data

Security

(public)

User Story

Attachments

(2 files)

Description

Comment 1

Comment 2

Comment 3

Comment 4

Comment 5

Comment 6

Comment 7

Comment 8

Comment 9

Comment 10

Comment 11

Comment 12

Comment 13

Comment 14

Comment 15

Attachment

General

Description

File Name

Content Type