Skip to content

Missing object files when linking with LTO #66285

Open

Description

Situation

I'm trying to add a dependency to SPIRV-Cross for Gecko, and I'm seeing linking errors (with undefined symbols) only in the "OS X Cross Compiled asan" job (cross-compiled macosx with address sanitizer and fuzziness. Non-fuzzy (non-asan) cross-compiled builds are fine.

This has been blocking a very large and important change to Gecko for about a week. I would appreciate any hints on how to approach this!

Problem

The objects of SPIRV-Cross are supposed to reach the linker by the following path:

  1. The C++ project is built into libspirv-cross-rust-wrapper.a by "cc-rs" that is invoked from the build.rs of spirv_cross crate
  2. That crates produces a regular Rust library that is statically linked with this .a file
  3. It is a dependency of other crates, eventually making its way to the gkrust crate, which is the root.
  4. libgkrust.a is a static C library build by Gecko
  5. Gecko static libraries are linked into XUL dynamic library

I can inspect libspirv-cross-rust-wrapper.a with llvm-objdump and I see everything is in place as expected: objdump-local.txt. I don't know how to properly inspect the rlib or rmeta of the Rust library products. I can, however, inspect libgkrust.a and see that some of the SPIRV-Cross objects didn't make it: libgkrust-objdump.txt (e.g. it has spirv_cfg.o but no spirv_cross.o). The selection appears to be arbitrary but consistent between compilations. From that, I conclude that the metadata about statically linked objects is not propagated through steps 2-3, which is what Cargo/Rustc are responsible for (!).

I'm able to reproduce the linking errors locally on linux, by downloading the artifacts and enabling both ASAN and fuzziness options in mozconfig-cross.txt. I confirmed that removing the "--enable-fuzzing" option makes it link fine.

I understand that this is a very big project, and it's not trivial to replicate the setup. However, so far, attempts to reproduce this on a reduced test case were not fruitful.

Further observations

It appears that Gecko has only handful of dependencies on C/C++ code by the vendored Rust crates, and all of them are either C or Obj-C, using clang for compiling (via "cc-rs" crate). SPIRV-Cross dependency is the only one in C++ using clang++, which makes it rather unique.

I'm also attaching the reduced verbose build log that only rebuilds spirv-cross related pieces:
detailed-build.log.

cc @jrmuizel @alexcrichton

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    A-crossArea: Cross compilationArea: Cross compilationA-linkageArea: linking into static, shared libraries and binariesArea: linking into static, shared libraries and binariesC-bugCategory: This is a bug.Category: This is a bug.O-macosOperating system: macOSOperating system: macOST-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions