Absolute path inclusions found in rule

[andrewkatson]

Description of the bug:

Whenever I try to build a protobuf cc library I get this error with some of the source protobuf files.

Starting local Bazel server and connecting to it...
INFO: Analyzed 3 targets (132 packages loaded, 4243 targets configured).
ERROR: C:/bazel-bin/external/protobuf~23.1/src/google/protobuf/BUILD.bazel:184:11: Compiling src/goo
gle/protobuf/port.cc [for tool] failed: absolute path inclusion(s) found in rule '@@protobuf~23.1//s
rc/google/protobuf:port_def':
the source file 'src/google/protobuf/port.cc' includes the following non-builtin files with absolute
 paths (if these are builtin files, make sure these paths are in your toolchain):
  'C:/bazel-bin/external/protobuf~23.1/src/google/protobuf/port_def.inc'
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 8.789s, Critical Path: 1.09s
INFO: 69 processes: 37 internal, 32 local.
ERROR: Build did NOT complete successfully

Repro: https://github.com/andrewkatson/protobuf_not_included

See: https://groups.google.com/g/protobuf/c/hwGG77sa1gA for more details

Which category does this issue belong to?

C++ Rules

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Try building the top level of https://github.com/andrewkatson/protobuf_not_included

Which operating system are you running Bazel on?

Windows 10

What is the output of bazel info release?

release 7.0.0

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 ?

git@github.com:andrewkatson/protobuf_not_included.git
894cb6730a339a21ce5cf5d0cf3f41b400175978

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

I can't go back that far because bzlmod didn't exist in bazel 4 when I last had this building.

Have you found anything relevant by searching the web?

Not that I could find

Any other information, logs, or outputs that you want to share?

No response

[comius]

This needs some investigation. Possibly the problem is in protobuf repo. Can you report it there as well?

[andrewkatson]

Ill report it there too!

[acozzette]

This seems to me like a Bazel bug, because we don't have an absolute #include there. The actual include looks like this: #include "google/protobuf/port_def.inc" Is it possible that Bazel is internally doing some kind of transformation that turns it into an absolute path?

[jwhpryor]

I'm also observing the same failure when compiling Jni Bind on Mac using Bazel. Any help would be appreciated if you make progress on this. FWIW, the mac test runner on GitHub does not seem to be effected.

[fmeum]

The paths Bazel complains about are directly obtained from the compiler. Since this issue isn't observed in Bazel's own CI, it would be helpful to get more information about the toolchains (Xcode, MSVC, ...) used during the builds where this fails. Also, does this still occur after a bazel clean --expunge?

[jwhpryor]

Oh! It does build and test successfully after calling bazel clean --expunge.

I don't have xcode (or at least, this does nothing): xcodebuild -version

Bazel version: 
Bazelisk version: development
Build label: 7.0.2
Build target: @@//src/main/java/com/google/devtools/build/lib/bazel:BazelServer
Build time: Thu Jan 25 16:14:15 2024 (1706199255)
Build timestamp: 1706199255
Build timestamp as int: 1706199255

As far as I'm aware, I didn't rev Bazel, and I have a .bazelversion pinned to 7.0.2.

Happy to provide any other details I can with the caveat that it now seems to be working after the expunge.

[oakad]

The same happens on bazel 7.2.1, so whatever this bug is, it is still around. Zlib, in my case, is pulled in by protobuf.

ERROR: /home/oakad/.cache/bazel/_bazel_oakad/ba946cf3cf08f87de0d02dc4d31d81f5/external/zlib~/BUILD.bazel:72:11: Compiling zutil.c [for tool] failed: absolute path inclusion(s) found in rule '@@zlib~//:zlib': the source file 'zutil.c' includes the following non-builtin files with absolute paths (if these are builtin files, make sure these paths are in your toolchain): '/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/include/stddef.h' '/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/include/limits.h' '/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/include/syslimits.h' '/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/include/stdarg.h' Target //:pkg-all failed to build

[nikhilkalige]

I saw similar issue recently, where an #include xbasic.h started showing up as /home/user/..../xbasic.h instead of .../virtual_includes/.../xbasic.h. I ran strace on gcc and I saw that it was calling readlink on these files. I don't understand why that is the case. On further debugging, the primary reason seems to be the use of -isystem vs -iquote.

I had made a small change to use cc_library(includes = [mypaths]) inplace of cc_library(copts = [-Imypaths]), and that was causing it. I see a few of your cases are not related to mine, but I thought I will put it out here if someone tries debugging the same problem.

I created a small rule to support quote_includes argument of create_compilation_context. I think this argument should be exposed to cc_library.

[oakad]

Looks like this is triggered when compiler toolchain is upgraded and is fixable by cleaning out the bazel cache in such cases. Which makes me think this is related to how bazel handles the includes external to the project, mostly those provided by the toolchain.