Linking failed: Could not copy inputs into sandbox: <path>/lib64 (Is a directory) #27028
Description
Description of the bug:
I'm using a custom cc_toolchain where I'm setting each attribute using filegroups obtained via globs, like the following:
cc_toolchain(
name = "_cc_toolchain",
all_files = ":all_files",
ar_files = ":ar_files",
as_files = ":as_files",
compiler_files = ":compiler_files",
... etc.
)
filegroup(
name = "all_files",
srcs = glob(["**"]),
)
... etc.
I'm also compiling my C++ files using cc_library/cc_binary in a Docker sandbox. There are 9000 files in the toolchain and that results in a lot of IO overhead. Trying to reduce the overhead, I've switched the filegroups to point to directories instead, but with no successful results.
-
With
filegroup(name = "all_files", srcs = ["."]):
I'm getting:
WARNING: Directory artifact crosses package boundary into package rooted at tools/toolchains
and
ERROR: external/+_repo_rules+flatbuffers/src/BUILD.bazel:9:11: Compiling src/idl_parser.cpp failed: Exec failed due to IOException: The file type of 'external/+_repo_rules2+gcc_10.3.0_x86_tool/x86_64-buildroot-linux-gnu/lib64/libgfortran.so.5' is not supported. -
Referencing individual directories, with
filegroup(name = "all_files", srcs = ["bin", "include", "lib", "lib64", ...]):
I'm getting:
ERROR: <path>/external/googletest+/BUILD.bazel:86:11: Linking external/googletest+/libgtest.so failed: Could not copy inputs into sandbox: <path>/execroot/_main/external/+_repo_rules2+gcc_10.3.0_x86_tool/lib64 (Is a directory)
Which category does this issue belong to?
Local Execution
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
No response
Which operating system are you running Bazel on?
WSL2 Ubuntu 22.04
What is the output of bazel info release?
release 8.4.1
If bazel info release returns development version or (@non-git), tell us how you built Bazel.
No response
What's the output of git remote get-url origin; git rev-parse HEAD ?
If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response