cc_library deps on bazel 0.25.x error

[ghost]

Not sure if this is rules_rust issue, or again upstream. I am getting error when trying to compile bactrace-sys using the cc_library as dependency. The bazel complains that backtrace target is neither rust_library, rust_*_library or cc_library.

Also following INFO messages are obtained:

Traceback (most recent call last):
        File "/home/urban/Work/virtualchemist/third_party/cargo/overload/backtrace-sys-0.1.28/BUILD", line 91
                rust_library(name = 'backtrace_sys')
        File "/home/urban/.cache/bazel/_bazel_urban/228edeacaae981c311aebaa15063220d/external/io_bazel_rules_rust/rust/private/rust.bzl", line 85, in _rust_library_impl
                rustc_compile_action(ctx = ctx, toolchain = toolchain, cr...)), ...)
        File "/home/urban/.cache/bazel/_bazel_urban/228edeacaae981c311aebaa15063220d/external/io_bazel_rules_rust/rust/private/rustc.bzl", line 180, in rustc_compile_action
                collect_deps(crate_info.deps, toolchain)
        File "/home/urban/.cache/bazel/_bazel_urban/228edeacaae981c311aebaa15063220d/external/io_bazel_rules_rust/rust/private/rustc.bzl", line 116, in collect_deps
                fail(("rust targets can only depend o...)), ...")
attribute deps: rust targets can only depend on rust_library, rust_*_library or cc_library targets.<target //third_party/cargo/overload/backtrace-sys-0.1.28:backtrace>
INFO: An error occurred during the fetch of repository 'remotejdk11_linux'
INFO: Call stack for the definition of repository 'remotejdk11_linux':
 - /DEFAULT.WORKSPACE.SUFFIX:178:1
INFO: An error occurred during the fetch of repository 'remote_java_tools_linux'
INFO: Call stack for the definition of repository 'remote_java_tools_linux':
 - /DEFAULT.WORKSPACE.SUFFIX:208:1 

Also on 0.24.x everything works. Any idea what changed on 0.25.x?

[acmcarther]

I don't have any insight into recent changes but one observation for now:

It seems unusual to me that we're seeing an issue with "remotejdk11" when compiling //third_party/cargo/overload/backtrace-sys-0.1.28:backtrace. Just as a sanity check, can you verify that //third_party/cargo/overload/backtrace-sys-0.1.28:backtrace is a cc_library?

The output of the following bazel command should be pretty complete and may be helpful to maintainers here familiar with recent changes (though please look through it to make sure nothing proprietary is being shared):

$ bazel query //third_party/cargo/overload/backtrace-sys-0.1.28:backtrace --output build

[ghost]

Hey, thanks for replying. The output is

# /home/urban/Work/vc/third_party/cargo/overload/backtrace-sys-0.1.28/BUILD:39:1
cc_library(
  name = "backtrace",
  defines = ["BACKTRACE_ELF_SIZE=64", "BACKTRACE_SUPPORTED=1", "BACKTRACE_USES_MALLOC=1", "BACKTRACE_SUPPORTS_THREADS=0", "BACKTRACE_SUPPORTS_DATA=0", "HAVE_DL_ITERATE_PHDR=1", "_GNU_SOURCE=1", "_LARGE_FILES=1", "backtrace_full=__rbt_backtrace_full", "backtrace_dwarf_add=__rbt_backtrace_dwarf_add", "backtrace_initialize=__rbt_backtrace_initialize", "backtrace_pcinfo=__rbt_backtrace_pcinfo", "backtrace_syminfo=__rbt_backtrace_syminfo", "backtrace_get_view=__rbt_backtrace_get_view", "backtrace_release_view=__rbt_backtrace_release_view", "backtrace_alloc=__rbt_backtrace_alloc", "backtrace_free=__rbt_backtrace_free", "backtrace_vector_finish=__rbt_backtrace_vector_finish", "backtrace_vector_grow=__rbt_backtrace_vector_grow", "backtrace_vector_release=__rbt_backtrace_vector_release", "backtrace_close=__rbt_backtrace_close", "backtrace_open=__rbt_backtrace_open", "backtrace_print=__rbt_backtrace_print", "backtrace_simple=__rbt_backtrace_simple", "backtrace_qsort=__rbt_backtrace_qsort", "backtrace_create_state=__rbt_backtrace_create_state", "backtrace_uncompress_zdebug=__rbt_backtrace_uncompress_zdebug"],
  includes = ["."],
  copts = ["-fvisibility=hidden"],
  srcs = ["//third_party/cargo/overload/backtrace-sys-0.1.28:touch_config_header", "//third_party/cargo/overload/backtrace-sys-0.1.28:touch_backtrace_supported_header", "//third_party/cargo/overload/backtrace-sys-0.1.28:src/libbacktrace/internal.h", "//third_party/cargo/overload/backtrace-sys-0.1.28:src/libbacktrace/backtrace.h", "//third_party/cargo/overload/backtrace-sys-0.1.28:src/libbacktrace/alloc.c", "//third_party/cargo/overload/backtrace-sys-0.1.28:src/libbacktrace/dwarf.c", "//third_party/cargo/overload/backtrace-sys-0.1.28:src/libbacktrace/fileline.c", "//third_party/cargo/overload/backtrace-sys-0.1.28:src/libbacktrace/posix.c", "//third_party/cargo/overload/backtrace-sys-0.1.28:src/libbacktrace/read.c", "//third_party/cargo/overload/backtrace-sys-0.1.28:src/libbacktrace/sort.c", "//third_party/cargo/overload/backtrace-sys-0.1.28:src/libbacktrace/state.c", "//third_party/cargo/overload/backtrace-sys-0.1.28:src/libbacktrace/elf.c"],
)

EDIT
I mostly took what @mfarrugi wrote here worked like a charm till 0.25.x

[damienmg]

@hlopko: Is there something that changed in C++ providers? It looks like the above cc_library is not detected by https://github.com/bazelbuild/rules_rust/blob/master/rust/private/rustc.bzl#L110

[ghost]

Just confirmed that problem remains on 0.25.2 release. Should this maybe be moved to bazelbuild/bazel?

Also tested on multiple computers... problem is always the same. Would be really grateful for any suggestions?

[ghost]

Happy to close this issue. The problem seems to be gone on bazel versions 0.26 and 0.27. with newest rules_rust. Not sure what changed tho.