Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
dwtj opened this issue Sep 20, 2019 · 7 comments
Open

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

dwtj opened this issue Sep 20, 2019 · 7 comments

Comments

@dwtj
Copy link

dwtj commented Sep 20, 2019 •
edited
Loading

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
Copy link
Collaborator

mfarrugi commented Sep 20, 2019 via email

@dwtj
Copy link
Author

dwtj commented Sep 20, 2019

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 added a commit to dwtj/bazel_integration_examples that referenced this issue Sep 20, 2019
@dwtj
Draft workaround for bad libstdc++ symlink on Arch
c73c774 
Overrides `@local_libstdcpp` as suggested in bazelbuild/rules_rust#251.
Unfortunately, this has revealed another problem. When the `bindgen`
command is invoked, the dynamic loading/linkage of `libclang.so` fails.
@dwtj
Copy link
Author

dwtj commented Sep 20, 2019 •
edited
Loading

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
Copy link
Collaborator

mfarrugi commented Sep 20, 2019 via email

@dwtj
Copy link
Author

dwtj commented Sep 20, 2019

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.

@GregBowyer GregBowyer mentioned this issue Jun 30, 2020
Open
@dwtj
Copy link
Author

dwtj commented Oct 11, 2020

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.)

@ddeville ddeville mentioned this issue Jan 7, 2022
Closed
@oconnor663
Copy link

oconnor663 commented Dec 2, 2022 •
edited
Loading

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@oconnor663 @mfarrugi @dwtj