Yoga 0.4.0 build failing (unable to read binding.rs from OUT_DIR)

[nicoburns]

Crate name

yoga

Build failure link

https://docs.rs/crate/yoga/0.4.0/builds/705324

Additional details

The error is:

[INFO] [stderr] Documenting yoga v0.4.0 (/opt/rustwide/workdir)
[INFO] [stderr] error: couldn't read /opt/rustwide/target/x86_64-unknown-linux-gnu/debug/build/yoga-4b1fce5c61a680df/out/bindings.rs: No such file or directory (os error 2)
[INFO] [stderr] --> src/lib.rs:16:5
[INFO] [stderr] |
[INFO] [stderr] 16 | include!(concat!(env!("OUT_DIR"), "/bindings.rs"));
[INFO] [stderr] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[INFO] [stderr] |
[INFO] [stderr] = note: this error originates in the macro include (in Nightly builds, run with -Z macro-backtrace for more info)
[INFO] [stderr]
[INFO] [stderr] error: could not document yoga

So it seems that it is unable to find the bindings.rs file in the OUT_DIR (which should be generated by bindgen in the build.rs), but there is not indication that the generation failed. I am unable to reproduce this locally either by running cargo doc in a cloned version of the yoga-rs repo or by adding the published version of the crate as a dependency and running cargo doc (both work fine).

Any ideas? It looks like it ought to work fine to me.

[syphar]

Sorry for the delay.

This is indeed a confusing error.
While I don't know (yet) why you don't see the related error, there is one thing that I see that could be an issue:

you are doing git submodule update in your build.rs, which implies a network connection. And we are blocking all network requests in the build container ( see also our docs).
Most libraries that bind other libraries probably vendor the headers, and/or have a special build purely for documentation, triggered by the docs.rs metadata.

cc @Nemo157 @jyn514 have to seen behaviour like this in the past?

[Nemo157]

Running the build in a local sandbox results in build.rs failing:

  fatal: not a git repository (or any parent up to mount point /tmp/tmp.k42iZf82EV)
  Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
  fatal: not a git repository (or any parent up to mount point /tmp/tmp.k42iZf82EV)
  Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
  src/yoga/yoga/Yoga.h:371:10: fatal error: 'functional' file not found
  thread 'main' panicked at 'Unable to generate bindings: ClangDiagnostic("src/yoga/yoga/Yoga.h:371:10: fatal error: 'functional' file not found\n")', build.rs:65:10

That seems to be related to a missing C++ standard library 🤔. Note, this doesn't actually check that git was successful, Command::new("git").args(["submodule", "init"]).status().expect("Unable to initialize git submodules") checks that you got a status code but doesn't check that that status was 0. So lack of network (or .git) shouldn't matter.

Trying with -Zrustdoc-scrape-examples too reproduces a similar error as docs.rs got, it appears that causes cargo to not notice that running the build-script failed and to try building the library anyway rust-lang/cargo#11623.

[nicoburns]

Excellent detective work!

That seems to be related to a missing C++ standard library 🤔

Indeed. The build.rs specifies .clang_arg("-stdlib=libc++") for bindgen (because otherwise the generated file fails to compile due to lack of ManuallyDrop being generated). I was able reproduce this error in a local Ubuntu 22.04 VM (although I would swear I previously had this library compiling in the same VM), and installing libc++-dev seems to fix the issue.

Alas that libc++dev seems to clash with some of the packages already being used in the build image (known ubuntu bug https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-14/+bug/1989124) so I'm not quite sure how to proceed at the moment. But assuming that the build issue can be fixed, is there a way to request/trigger a docs rebuild without publishing a new library version?

[Nemo157]

Yes, once the build image is updated and deployed we can queue a new build.

[Nemo157]

The upstream cargo issue has been fixed and should be in the latest nightly, so I've queued a new build that I expect to fail with the correct error message just to confirm.

[nicoburns]

New build is here: https://docs.rs/crate/yoga/0.4.0/builds/746419. I can confirm that the build is now failing with the correct error message.

[syphar]

@nicoburns thanks for the update!

This means you can now continue debugging the issue? Or do you need more input / help?

[nicoburns]

@syphar I actually know what the issue is:

• I'm building against libc++ instead of libstdc++ because of this bug with bindgen Tagged unions inside template fail to build. rust-bindgen#2157 (comment)
• The docs.rs build environment doesn't include libc++ headers so this fails
• And the PR to add it can't be merged because this ubuntu bug means that libc++-dev clashes with libunwind which is already part of the build image.

If you have idea how to resolve that then help would be appreciated! But it's a bit of a tricky one.

[syphar]

From what (little) I know about the ecosystem, otherways include:

• vendor the needed headers, or the generated code
• if the headers are not needed for the public interface (aka, for the docs), use conditional compilation to generate the docs without having the headers

see also https://docs.rs/about/builds

[syphar]

@nicoburns did you get any further with this issue?

In my mind, conditional compilation or vendoring is probably the best bet,

alternatively finding our why / when libunwind was added (I can check when I'm back at my computer) and see if we could remove it.