The provided `example-bindgen-toolchain` rule does not find `libstdc++.so.6` on ArchLinux because of a broken symlink

[dwtj]

I've made this minimum working example Bazel workspace (.zip) to demonstrate the problem I'm having building rust_bindgen_library targets on ArchLinux.

It just has a rust_bindgen_library rule pointing to a trivial cc_library and its header file. bindgen_toolchain resolves to the example-bindgen-toolchain (i.e. the one registered while calling the rust_bindgen_repositories() workspace rule).

I cannot bazel build //... this workspace on my ArchLinux system. I get the following error.

ERROR: missing input file '@local_libstdcpp//:libstdc++.so.6'
ERROR: /home/dwtj/.cache/bazel/_bazel_dwtj/b8ac5acf45adefed9426377fa8b7244a/external/local_libstdcpp/BUILD.bazel:2:1: @local_libstdcpp//:libstdc++: missing input file '@local_libstdcpp//:libstdc++.so.6'
ERROR: /home/dwtj/.cache/bazel/_bazel_dwtj/b8ac5acf45adefed9426377fa8b7244a/external/local_libstdcpp/BUILD.bazel:2:1 1 input file(s) do not exist

The problem appears to be that @local_libstdcpp's symlink to libstdc++.so is broken.

lrwxrwxrwx 1 dwtj dwtj 40 Sep 19 15:37 /home/dwtj/.cache/bazel/_bazel_dwtj/b8ac5acf45adefed9426377fa8b7244a/external/local_libstdcpp/libstdc++.so.6 -> /usr/lib/x86_64-linux-gnu/libstdc++.so.6

But libstdc++.so.6 is not located at that location on my ArchLinux system. It is at /usr/lib/libstdc++.so.6.

I think that the problem stems from assumption about Linux made here:

rules_rust/bindgen/repositories.bzl

Lines 76 to 79 in f727669

	def _local_libstdcpp_impl(repository_ctx):
	os = repository_ctx.os.name.lower()
	if os == "linux":
	repository_ctx.symlink("/usr/lib/x86_64-linux-gnu/libstdc++.so.6", "libstdc++.so.6")

Presumably this is the usual location of libstdc++.so.6 on other distros.

I realize that I can work around this issue by creating and registering my own bindgen_toolchain instance, following example-bindgen-toolchain as a guide. That's my next move.

The current example-bindgen-toolchain implementation seems a bit brittle in how it creates this symlink. But I'm afraid that I don't know enough Bazel-fu to immediately recommend some way to make it less brittle.

[mfarrugi]

https://github.com/bazelbuild/rules_rust/blob/f727669b8ac3c9d237ed9bc7833b8e1eeec90506/bindgen/repositories.bzl#L28-L31 lets you define your own `local_libstdcpp` that the toolchain will then pickup. The example is extremely brittle because of the non-uniform way libstdc++ is distributed, the surface level fix is to keep adding branches to the os if statement. IIRC the cc rules should also have to deal with the problem of finding and linking libstdc++, and our rules should be able to consult the cc rules for that, but I could not find out how that is done.

…

On Fri, Sep 20, 2019 at 12:19 AM David Johnston ***@***.***> wrote: I've made this minimum working example Bazel workspace <https://github.com/bazelbuild/rules_rust/files/3634145/bazel_rust_bindgen.zip> (.zip) to demonstrate the problem I'm having building rust_bindgen_library targets on ArchLinux. It just has a rust_bindgen_library rule pointing to a trivial cc_library and its header file. bindgen_toolchain resolves to the example-bindgen-toolchain (i.e. the one registered while calling the rust_bindgen_repositories() workspace rule). I cannot bazel build //... this workspace on my ArchLinux system. I get the following error. ERROR: missing input file ***@***.***_libstdcpp//:libstdc++.so.6' ERROR: /home/dwtj/.cache/bazel/_bazel_dwtj/b8ac5acf45adefed9426377fa8b7244a/external/local_libstdcpp/BUILD.bazel:2:1: @local_libstdcpp//:libstdc++: missing input file ***@***.***_libstdcpp//:libstdc++.so.6' ERROR: /home/dwtj/.cache/bazel/_bazel_dwtj/b8ac5acf45adefed9426377fa8b7244a/external/local_libstdcpp/BUILD.bazel:2:1 1 input file(s) do not exist The problem appears to be because @local_libstdcpp's symlink to libstdc++.so appears to be broken. lrwxrwxrwx 1 dwtj dwtj 40 Sep 19 15:37 /home/dwtj/.cache/bazel/_bazel_dwtj/b8ac5acf45adefed9426377fa8b7244a/external/local_libstdcpp/libstdc++.so.6 -> /usr/lib/x86_64-linux-gnu/libstdc++.so.6 But libstdc++.so.6 is not located at that location on my ArchLinux system. It is at /usr/lib/libstdc++.so.6. The problem appears to be with an assumption about Linux made here: https://github.com/bazelbuild/rules_rust/blob/f727669b8ac3c9d237ed9bc7833b8e1eeec90506/bindgen/repositories.bzl#L76-L79 Presumably this is the usual location of libstdc++.so.6 on other distros. I realize that I can work around this issue by creating and registering my own bindgen_toolchain instance, following example-bindgen-toolchain as a guide. That's my next move. I'm afraid that I don't know enough Bazel-fu to immediately recommend some way to make the current example-bindgen-toolchain less brittle. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#251?email_source=notifications&email_token=AAROG6BPGOIQMYWE5CJKYYDQKRFNNA5CNFSM4IYSRBE2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HMSN5ZA>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAROG6C4DXRVXCCADBQRDGLQKRFNNANCNFSM4IYSRBEQ> .

[dwtj]

rules_rust/bindgen/repositories.bzl

Lines 28 to 31 in f727669

	maybe(
	_local_libstdcpp,
	name = "local_libstdcpp",
	)

lets you define your own local_libstdcpp that the toolchain will then pickup.

I wasn't previously familiar with the maybe Bazel idiom or the native.existing_rule() function on which it relies. Just defining my own @local_libstdcpp will be better than assembling and registering a whole different toolchain. Thanks for the tip, @mfarrugi.

[dwtj]

FYI. I just spent a few minutes implementing the suggested workaround, but it revealed another problem. When the cargo-raze-built bindgen executable is invoked, it appears to fail with the error "Unable to find libclang", caused by "Unable to find libtinfo".

ERROR: /home/dwtj/Projects/bazel_integration_examples/bazel_rust_bindgen/my_rust_bindgen_library/BUILD.bazel:3:1: Generating bindings for my_cc_library/hello.h.. failed (Exit 101) cargo_bin_bindgen failed: error executing command bazel-out/host/bin/external/raze__bindgen__0_40_0/cargo_bin_bindgen --no-rustfmt-bindings my_cc_library/hello.h --output ... (remaining 6 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox
thread 'main' panicked at 'Unable to find libclang: "the `libclang` shared library at bazel-out/host/bin/_solib_k8/_U@bindgen_Uclang_S_S_Clibclang.so___Uexternal_Sbindgen_Uclang_Slib/libclang.so could not be opened: libtinfo.so.5: cannot open shared object file: No such file or directory"', src/libcore/result.rs:997:5

If I inspect this libclang.so nested within bazel-out, it is indeed missing the dynamic library libtinfo, specifically, libtinfo.so.5:

[dwtj@ash _U@bindgen_Uclang_S_S_Clibclang.so___Uexternal_Sbindgen_Uclang_Slib]$ ldd libclang.so 
ldd: warning: you do not have execution permission for `./libclang.so'
	linux-vdso.so.1 (0x00007ffcfb1ba000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f507445e000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007f5074247000)
	librt.so.1 => /usr/lib/librt.so.1 (0x00007f507423c000)
	libtinfo.so.5 => not found
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f507421b000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007f50740d5000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f5073eeb000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f5073ed1000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007f5073d0e000)
	/usr/lib64/ld-linux-x86-64.so.2 (0x00007f507860f000)

libtinfo appears to be a "low-level terminal info" library provided with ncurses. I added this library with the ArchLinux package manager (specifically pacman -S ncurses) and made a symlink from /usr/lib/libinfo.so.6 to /usr/lib/libinfo.so.5. Now bindgen runs as expected.

Obviously, my workaround was very specific to my system. I'm just leaving it here

• In case anyone else runs into similar trouble.
• To demonstrate that the provided clang (i.e. the @bindgen_clang external repository) isn't quite self-contained.

[mfarrugi]

That's unfortunate, thanks for leaving the note. It might be a better story for hermeticity to pull binaries from Nix at some point, although that creates problems with Windows compatibility.

…

On Fri, Sep 20, 2019, 04:40 David Johnston ***@***.***> wrote: FYI. I just spent a few minutes implementing the suggested workaround, but it revealed another problem. When the cargo-raze-built bindgen executable is invoked, it appears to fail with the error "Unable to find libclang", caused by "Unable to find libtinfo". ERROR: /home/dwtj/Projects/bazel_integration_examples/bazel_rust_bindgen/my_rust_bindgen_library/BUILD.bazel:3:1: Generating bindings for my_cc_library/hello.h.. failed (Exit 101) cargo_bin_bindgen failed: error executing command bazel-out/host/bin/external/raze__bindgen__0_40_0/cargo_bin_bindgen --no-rustfmt-bindings my_cc_library/hello.h --output ... (remaining 6 argument(s) skipped) Use --sandbox_debug to see verbose messages from the sandbox thread 'main' panicked at 'Unable to find libclang: "the `libclang` shared library at ***@***.***_Uclang_S_S_Clibclang.so___Uexternal_Sbindgen_Uclang_Slib/libclang.so could not be opened: libtinfo.so.5: cannot open shared object file: No such file or directory"', src/libcore/result.rs:997:5 If I inspect this libclang.so nested within bazel-out, it is indeed missing the dynamic library libtinfo, specifically, libtinfo.so.5: ***@***.*** ***@***.***_Uclang_S_S_Clibclang.so___Uexternal_Sbindgen_Uclang_Slib]$ ldd libclang.so ldd: warning: you do not have execution permission for `./libclang.so' linux-vdso.so.1 (0x00007ffcfb1ba000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f507445e000) libz.so.1 => /usr/lib/libz.so.1 (0x00007f5074247000) librt.so.1 => /usr/lib/librt.so.1 (0x00007f507423c000) libtinfo.so.5 => not found libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f507421b000) libm.so.6 => /usr/lib/libm.so.6 (0x00007f50740d5000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f5073eeb000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f5073ed1000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f5073d0e000) /usr/lib64/ld-linux-x86-64.so.2 (0x00007f507860f000) libtinfo appears to be a "low-level terminal info" library provided with ncurses. I added this library ArchLinux package manager (via pacman -S ncurses) and made a symlink from /usr/lib/libinfo.so.6 to /usr/lib/libinfo.so.6. Now bindgen runs as expected. Obviously, my workaround was very specific to my system. I'm just leaving it here - In case anyone else runs into similar trouble. - To demonstrate that the provided clang (i.e. the @bindgen_clang external repository) isn't completely self-contained. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#251?email_source=notifications&email_token=AAROG6EEDVL6FLP6OTRXJH3QKSEBTA5CNFSM4IYSRBE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7GAOBA#issuecomment-533464836>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAROG6ESBXP2DQTQEQYYQHDQKSEBTANCNFSM4IYSRBEQ> .

[dwtj]

I haven't looked into it at all yet, but maybe grailbio/bazel-toolchain, an "LLVM toolchain for Bazel", can help fetch and package a more hermetic clang.

[dwtj]

FYI: I ran into both of my above-described problems on my Fedora 32 Linux development system as well as on ArchLinux. To recap, these two problems were fixed by:

• Defining my own @local_libstdcpp to fix its broken symlink.
• Symlinking libinfo.so.6 to libinfo.so.5 to make the libclang.so provided with @bindgen_clang find libinfo.so.5. (Fingers crossed that this new version is compatible.)

[oconnor663]

A note for other folks doing the same workaround: I found that symlinking libinfo.so.5 no longer works on Arch Linux. I got this error: /usr/lib/libtinfo.so.5: version `NCURSES_TINFO_5.0.19991023' not found. (Not too surprising that it's looking for version-specific symbols and catching my lie.) Instead, what worked for me was installing ncurses5-compat-libs from the AUR.