Bazel + MSVC C++ = missing dependency declarations [culprit #5136] #5640

derekmauro · 2018-07-19T15:13:22Z

Description of the problem / feature request:

We are getting a spurious this rule is missing dependency declarations for the following files included by ... when using MSVC to build on Windows. I say it is spurious because the same command works correctly on Linux and OSX, and I've verified the BUILD rule is correct.

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

On Windows + MSVC:

git clone https://github.com/abseil/abseil-cpp.git
bazel test --define absl=1 absl/...

The --define absl=1 part makes Google Test use Abseil. So Abseil tests uses Google Test, which in turn uses the Abseil libraries. I'm not sure if the circular project dependency has anything to do with this. Everything works as expected without --define absl=1.

Output on my machine:

PS C:\Users\dmauro\abseil-cpp> bazel --bazelrc=/dev/null test --define absl=1 absl/...
Loading:
Loading: 0 packages loaded
INFO: Build options have changed, discarding analysis cache.
Analyzing: 157 targets (16 packages loaded)
INFO: Analysed 157 targets (34 packages loaded).
INFO: Found 55 targets and 102 test targets...
[0 / 11] [-----] Creating source manifest for //absl/strings:ascii_test
[10 / 33] Compiling external/com_google_absl/absl/strings/charconv.cc; 1s local ... (4 actions running)
[15 / 33] Compiling external/com_google_absl/absl/strings/substitute.cc; 1s local ... (4 actions, 3 running)
[19 / 33] Compiling external/com_google_absl/absl/strings/str_cat.cc; 1s local ... (4 actions, 3 running)
[24 / 38] Compiling external/com_google_absl/absl/strings/str_replace.cc; 1s local ... (3 actions running)
[36 / 55] Compiling external/com_google_absl/absl/debugging/failure_signal_handler.cc; 0s local ... (4 actions running)
[39 / 58] Compiling external/com_google_absl/absl/debugging/failure_signal_handler.cc; 1s local ... (4 actions running)
[45 / 66] Compiling absl/base/internal/spinlock.cc; 1s local ... (4 actions, 3 running)
[54 / 78] Compiling external/com_google_absl/absl/base/internal/low_level_alloc.cc; 1s local ... (4 actions running)
[55 / 79] Compiling external/com_google_googletest/googletest/src/gtest-death-test.cc; 2s local ... (4 actions running)
[60 / 84] Compiling external/com_google_googletest/googletest/src/gtest.cc; 2s local ... (3 actions running)
[64 / 89] Compiling external/com_google_googletest/googletest/src/gtest-printers.cc; 2s local ... (4 actions running)
[73 / 98] Compiling absl/strings/str_replace.cc; 1s local ... (4 actions running)
[86 / 113] Compiling external/com_google_absl/absl/base/internal/spinlock.cc; 1s local ... (4 actions running)
ERROR: C:/users/dmauro/abseil-cpp/absl/strings/BUILD.bazel:148:1: undeclared inclusion(s) in rule '//absl/strings:ascii_
test':
this rule is missing dependency declarations for the following files included by 'absl/strings/ascii_test.cc':
  'absl/types/optional.h'
  'absl/utility/utility.h'
  'absl/types/bad_optional_access.h'
  'absl/types/variant.h'
  'absl/types/internal/variant.h'
  'absl/types/bad_variant_access.h'
INFO: Elapsed time: 29.078s, Critical Path: 4.50s
INFO: 71 processes: 71 local.
FAILED: Build did NOT complete successfully

It's interesting that I see both Compiling absl/base/internal/spinlock.cc; and external/com_google_absl/absl/base/internal/low_level_alloc.cc; (note the external/com_google_absl prefix). It is as if Bazel doesn't understand that the root WORKSPACE, named com_google_absl, isn't the same Abseil that Google Test depends on, even though it depends on Abseil under the name com_google_absl. A Linux build never shows the external/com_google_absl in the output.

What operating system are you running Bazel on?

Windows 2008 R2 on GCP. I also tried it on a Kokoro instance (not sure of the Windows version of that) and got the same result.

What's the output of `bazel info release`?

PS C:\Users\dmauro\abseil-cpp> bazel version
Build label: 0.15.0
Build target: bazel-out/x64_windows-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Tue Jun 26 12:09:42 2018 (1530014982)
Build timestamp: 1530014982
Build timestamp as int: 1530014982
PS C:\Users\dmauro\abseil-cpp> bazel info release
release 0.15.0

What's the output of `git remote get-url origin ; git rev-parse master ; git rev-parse HEAD` ?

PS C:\Users\dmauro\abseil-cpp> git remote get-url origin ; git rev-parse master ; git rev-parse HEAD
https://github.com/abseil/abseil-cpp.git
2c5af55ed34850d8b7dd46177c8ca53fdfda920e
2c5af55ed34850d8b7dd46177c8ca53fdfda920e

Have you found anything relevant by searching the web?

#5087 is possibly the same issue, but I'm not sure. That issue refers to remote workers.

The text was updated successfully, but these errors were encountered:

rongjiecomputer · 2018-07-20T10:13:09Z

I can reproduce the issue with Bazel from master branch and VS 2017 15.7 and Clang on Windows (master).

@derekmauro I have some idea, but I will need your help to verify it. Can you do the following on Linux machine with GCC/Clang?

Run bazel test --define absl=1 //absl/base:throw_delegate_test
Modify throw_delegate_test.cc.
Run bazel test --define absl=1 //absl/base:throw_delegate_test -s
Paste the console output here (I am only interested in the subcommand when compiling throw_delegate_test.cc).

derekmauro · 2018-07-20T14:11:34Z

Output from step 3:

$ bazel test --define absl=1 //absl/base:throw_delegate_test -s
INFO: Analysed target //absl/base:throw_delegate_test (0 packages loaded).
INFO: Found 1 test target...
SUBCOMMAND: # //absl/base:throw_delegate_test [action 'Compiling absl/base/throw_delegate_test.cc']
(cd /home/dmauro/.cache/bazel/_bazel_dmauro/e240e8f4f46ded87fd03013f5525686b/execroot/com_google_absl && \
  exec env - \
    PATH=/home/dmauro/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
    PWD=/proc/self/cwd \
  /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -B/usr/bin -B/usr/bin -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer '-std=c++0x' -MD -MF bazel-out/k8-fastbuild/bin/absl/base/_objs/throw_delegate_test/absl/base/throw_delegate_test.pic.d '-frandom-seed=bazel-out/k8-fastbuild/bin/absl/base/_objs/throw_delegate_test/absl/base/throw_delegate_test.pic.o' -fPIC -D__CLANG_SUPPORT_DYN_ANNOTATION__ '-DGTEST_HAS_ABSL=1' -iquote . -iquote bazel-out/k8-fastbuild/genfiles -iquote external/bazel_tools -iquote bazel-out/k8-fastbuild/genfiles/external/bazel_tools -iquote external/com_google_googletest -iquote bazel-out/k8-fastbuild/genfiles/external/com_google_googletest -iquote external/com_google_absl -iquote bazel-out/k8-fastbuild/genfiles/external/com_google_absl -isystem external/com_google_googletest/googlemock -isystem bazel-out/k8-fastbuild/genfiles/external/com_google_googletest/googlemock -isystem bazel-out/k8-fastbuild/bin/external/com_google_googletest/googlemock -isystem external/com_google_googletest/googlemock/include -isystem bazel-out/k8-fastbuild/genfiles/external/com_google_googletest/googlemock/include -isystem bazel-out/k8-fastbuild/bin/external/com_google_googletest/googlemock/include -isystem external/com_google_googletest/googletest -isystem bazel-out/k8-fastbuild/genfiles/external/com_google_googletest/googletest -isystem bazel-out/k8-fastbuild/bin/external/com_google_googletest/googletest -isystem external/com_google_googletest/googletest/include -isystem bazel-out/k8-fastbuild/genfiles/external/com_google_googletest/googletest/include -isystem bazel-out/k8-fastbuild/bin/external/com_google_googletest/googletest/include -Wall -Wextra -Wcast-qual -Wconversion-null -Wmissing-declarations -Woverlength-strings -Wpointer-arith -Wunused-local-typedefs -Wunused-result -Wvarargs -Wvla -Wwrite-strings -Wno-sign-compare -Wno-conversion-null -Wno-missing-declarations -Wno-sign-compare -Wno-unused-function -Wno-unused-parameter -Wno-unused-private-field -fexceptions -fno-canonical-system-headers -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -c absl/base/throw_delegate_test.cc -o bazel-out/k8-fastbuild/bin/absl/base/_objs/throw_delegate_test/absl/base/throw_delegate_test.pic.o)
SUBCOMMAND: # //absl/base:throw_delegate_test [action 'Linking absl/base/throw_delegate_test']
(cd /home/dmauro/.cache/bazel/_bazel_dmauro/e240e8f4f46ded87fd03013f5525686b/execroot/com_google_absl && \
  exec env - \
    PATH=/home/dmauro/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
    PWD=/proc/self/cwd \
  /usr/bin/gcc -o bazel-out/k8-fastbuild/bin/absl/base/throw_delegate_test '-Wl,-rpath,$ORIGIN/../../_solib_k8/' -Lbazel-out/k8-fastbuild/bin/_solib_k8 -pthread '-fuse-ld=gold' -Wl,-no-as-needed -Wl,-z,relro,-z,now -B/usr/bin -B/usr/bin -pass-exit-codes -Wl,-S -Wl,@bazel-out/k8-fastbuild/bin/absl/base/throw_delegate_test-2.params)
SUBCOMMAND: # //absl/base:throw_delegate_test [action 'Testing //absl/base:throw_delegate_test']
(cd /home/dmauro/.cache/bazel/_bazel_dmauro/e240e8f4f46ded87fd03013f5525686b/execroot/com_google_absl && \
  exec env - \
    JAVA_RUNFILES=bazel-out/k8-fastbuild/bin/absl/base/throw_delegate_test.runfiles \
    PATH=/home/dmauro/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
    PYTHON_RUNFILES=bazel-out/k8-fastbuild/bin/absl/base/throw_delegate_test.runfiles \
    RUNFILES_DIR=bazel-out/k8-fastbuild/bin/absl/base/throw_delegate_test.runfiles \
    RUN_UNDER_RUNFILES=1 \
    TEST_BINARY=absl/base/throw_delegate_test \
    TEST_INFRASTRUCTURE_FAILURE_FILE=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.infrastructure_failure \
    TEST_LOGSPLITTER_OUTPUT_FILE=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.raw_splitlogs/test.splitlogs \
    TEST_PREMATURE_EXIT_FILE=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.exited_prematurely \
    TEST_SIZE=medium \
    TEST_SRCDIR=bazel-out/k8-fastbuild/bin/absl/base/throw_delegate_test.runfiles \
    TEST_TARGET=//absl/base:throw_delegate_test \
    TEST_TIMEOUT=300 \
    TEST_TMPDIR=_tmp/5cb1cd4ee5a296cc53b755bf19211d99 \
    TEST_UNDECLARED_OUTPUTS_ANNOTATIONS=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.outputs_manifest/ANNOTATIONS \
    TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.outputs_manifest \
    TEST_UNDECLARED_OUTPUTS_DIR=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.outputs \
    TEST_UNDECLARED_OUTPUTS_MANIFEST=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.outputs_manifest/MANIFEST \
    TEST_UNDECLARED_OUTPUTS_ZIP=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.outputs/outputs.zip \
    TEST_UNUSED_RUNFILES_LOG_FILE=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.unused_runfiles_log \
    TEST_WARNINGS_OUTPUT_FILE=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.warnings \
    TEST_WORKSPACE=com_google_absl \
    TZ=UTC \
    XML_OUTPUT_FILE=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.xml \
  external/bazel_tools/tools/test/test-setup.sh absl/base/throw_delegate_test)
Target //absl/base:throw_delegate_test up-to-date:
  bazel-bin/absl/base/throw_delegate_test
INFO: Elapsed time: 1.118s, Critical Path: 0.91s
INFO: 3 processes: 3 linux-sandbox.
INFO: Build completed successfully, 4 total actions
//absl/base:throw_delegate_test                                          PASSED in 0.1s

Executed 1 out of 1 test: 1 test passes.
There were tests whose specified size is too big. Use the --test_verbose_timeoutINFO: Build completed successfully, 4 total actions

rongjiecomputer · 2018-07-20T15:10:55Z

Thanks for the console output. It disprove my guess that the include flags -I might be different for GCC/Clang and MSVC. Bazel always add include path . before external/com_google_absl regardless of compilers.

From what I can see in Bazel's java code, Bazel handles MSVC's /showIncludes output and GCC/Clang's -MD ouput in different code path (see 0), but the validation seems to be done in the same function (see 1). Java code is not my expertise, so I think I will stop here.

rongjiecomputer · 2018-08-08T04:28:24Z

@meteorcloudy @mhlopko Can you take a look?

meteorcloudy · 2018-08-08T07:25:54Z

@rongjiecomputer Thanks for the help, I'll take it from here.

meteorcloudy · 2018-08-08T09:30:01Z

@derekmauro I've debugged on this and found the root cause. Let me explain how this issue happened on Windows and not on Linux.

First, the google test framework depends on a certain version of absel. See
https://github.com/google/googletest/blob/master/WORKSPACE. Bazel downloads it as an external repository, that's why external/com_google_absl/absl/... exists. It will be compiled when enabling define absl=1. This is also true on Linux.

$ bazel query 'somepath(//absl/strings:ascii_test, @com_google_absl//absl/types:optional)'
//absl/strings:ascii_test
@com_google_googletest//:gtest_main
@com_google_googletest//:gtest
@com_google_absl//absl/types:optional

When compiling absl/strings/ascii_test.cc, two include directories will be added - . and external/com_google_absl. Both directories contains absl/types/optional.h and other header files. The first one will be detected by the compiler, but only the second one is declared as dependency of the test. The dependency check thus failed.
It didn't happen on Linux because sandbox is enabled by default. Since absl/types/optional.h is not declared as dependency, the compiler won't see it. If you build with --spawn_strategy=standalone, you'll get the same error as Windows.

@dslomov Is there anyway to override @com_google_absl in googletest to point to the local absl repository ?

dslomov · 2018-08-08T10:52:27Z

Not right now, but there will be once experimental_enable_repo_mapping is fully finished and #3115 is fixed.

meteorcloudy · 2018-08-13T08:46:23Z

@dslomov Thanks! Then I'll assign this to you.

meteorcloudy · 2018-08-29T10:39:56Z

FYI @laszlocsomor, this is the similar bug you encountered recently.

meteorcloudy · 2018-08-29T11:24:03Z

/cc @mhlopko This issue happens when you have the same header file under /I. and /Iextenral/<repository_name>, I guess we don't have any other way to avoid the conflict except enabling sandbox? (which only available on Unix).

laszlocsomor · 2018-08-29T11:38:28Z

@mhlopko, @meteorcloudy : I think the culprit is that every action runs in the same execution root. I believe the single execution root is the reason the compilation action has /Iexternal/foo -- to enable compiling cc_* rules even when they are in external repos.

laszlocsomor · 2018-08-29T11:39:54Z

And I believe we could solve this problem if all build actions corresponding to rules in external repos would use <execroot>/external/<reponame> as their execution root, and only the main repo's build actions would use <execroot>.

meteorcloudy · 2018-08-29T11:51:07Z

@laszlocsomor What if you have a cc_library lib.cc in your main repo, which depends on repo_x and includes foo/bar/x.h under <execroot>/external/repo_x. And you happen to have foo/bar/x.h under your source tree. We'll still have the same problem during compiling lib.cc, because /I. and /Iexternal/repo_x (relative to <execroot>) are both passed to the compiler.

rongjiecomputer · 2018-08-29T11:52:06Z

If /I. is added only after all the /Iexternal/repo, it should solve the issue Abseil is having, but I afraid that other issues might arise.

meteorcloudy · 2018-08-29T11:59:41Z

@rongjiecomputer Yes, that would be wrong if the actual file you want to include is in your main repo instead of external repo. I think the only way to make it right is sandbox, this way it can keep the compiler from accidentally discovering undeclared include files. (although there could still be header file conflicts between declared dependencies).

laszlocsomor · 2018-08-29T12:08:56Z

@meteorcloudy : Indeed you're right.

I also forgot to consider @repo//bar/b.cc may #include "bar/b.h", but @repo//bar:b may depend on rules in other external repos (e.g. @oper//qux:c), so even if the effective execution root for compiling @repo//bar:b were <execroot>/external/repo, this directory would have to contain a symlink <execroot>/external/repo/external/oper pointing to <execroot>/external/oper.

Update: fixed repo paths.

laszlocsomor · 2018-08-29T12:10:02Z

Correction: the symlink would have to be <execroot>/external/repo/external/oper, and point to <execroot>/external/oper. (Fixed in previous post.)

laszlocsomor · 2018-08-29T12:12:31Z

@meteorcloudy :

although there could still be header file conflicts between declared dependencies

Right, for example when a library depends on both //foo:x and @repo//foo:x and those both have foo/x.h in hdrs.

laszlocsomor · 2018-08-29T12:18:12Z

I think the include scanner could catch this error and suggest a fix ("Did you mean to include external/repo/foo/x.h instead of foo/x.h?"). Bazel knows the allowed set of included headers, so the include scanner could detect if an illegally included header file exists under one of the external repos.

meteorcloudy · 2018-08-29T13:08:18Z

the include scanner could catch this error and suggest a fix ("Did you mean to include external/repo/foo/x.h instead of foo/x.h?")

I agree.

laszlocsomor · 2018-08-29T13:42:37Z

After in-person discussion with @mhlopko and @meteorcloudy, it became clear that including files via "external/reponame" is in fact the wrong approach.

When a header file (lib/x.h) includes another file from its own package (lib/y.h), the inclusion path will be repo-relative. But if these headers are in an external repo (@foo) and a file in the main repo (main.cc) includes the first header as external/foo/lib/x.h, then the header's own inclusion path will now be wrong because it is missing the external/foo/ part.

The author of lib/x.h of course cannot foresee what external repo names their code will be imported under, so they cannot write future-proof include paths under external/. That's why repo-relative include paths must remain supported even for headers included from external repos, and my idea of including via external/foo/ is misguided.

Avoid include collision inside the Bazel source tree when a rule depends on @bazel_tools//tools/cpp/runfiles and includes "tools/cpp/runfiles/runfiles.h", but they end up getting "tools/cpp/runfiles/runfiles.h" from the main repo. Change-Id: Ic0fa23045b25cf9b1987780f9e752a54fa32be45 Details: bazelbuild#5640 (comment)

Avoid include collision inside the Bazel source tree when a rule depends on @bazel_tools//tools/cpp/runfiles and includes "tools/cpp/runfiles/runfiles.h", but they end up getting "tools/cpp/runfiles/runfiles.h" from the main repo. Change-Id: Ic0fa23045b25cf9b1987780f9e752a54fa32be45 Details: #5640 (comment) Closes #6023. Change-Id: Ic0fa23045b25cf9b1987780f9e752a54fa32be45 PiperOrigin-RevId: 210878008

gennadiycivil · 2018-11-09T13:56:18Z

Thabk you for the suggestion. googletest is a standalone repo which is serving thousands of users. We can't just merge it with abseil . Looks like windows sandboxing would br the answer . Thanks again G

…

On Fri, Nov 9, 2018, 05:03 László Csomor ***@***.*** wrote: @gennadiycivil <https://github.com/gennadiycivil> : The build works on Linux because of sandboxing. If you disable sandboxing with --spawn_strategy=standalone, the build breaks on Linux too: $ bazel build --define absl=1 absl/... --spawn_strategy=standalone Starting local Bazel server and connecting to it... INFO: Analysed 204 targets (42 packages loaded, 1882 targets configured). INFO: Found 204 targets... ERROR: /usr/local/google/home/laszlocsomor/stuff/abseil-cpp/absl/time/internal/cctz/BUILD.bazel:79:1: undeclared inclusion(s) in rule '//absl/time/internal/cctz:time_zone_format_test': this rule is missing dependency declarations for the following files included by 'absl/time/internal/cctz/src/time_zone_format_test.cc': 'absl/strings/string_view.h' 'absl/base/config.h' 'absl/base/policy_checks.h' 'absl/base/internal/throw_delegate.h' 'absl/base/macros.h' 'absl/base/port.h' 'absl/base/attributes.h'e 'absl/base/optimization.h' 'absl/types/optional.h' 'absl/utility/utility.h' 'absl/base/internal/inline_variable.h' 'absl/base/internal/identity.h' 'absl/base/internal/invoke.h' 'absl/meta/type_traits.h' 'absl/memory/memory.h' 'absl/types/bad_optional_access.h' 'absl/types/variant.h' 'absl/types/internal/variant.h' 'absl/types/bad_variant_access.h' INFO: Elapsed time: 8.772s, Critical Path: 4.63s, Remote (0.00% of the time): [queue: 0.00%, setup: 0.00%, process: 0.00%] INFO: 83 processes: 83 local. FAILED: Build did NOT complete successfully We can fix this problem in one of two ways: - implement sandboxing on Windows - merge the Abseil and GoogleTest repos and remove external repo references to each other In fact I just did that (merging the repos): 1. I looked at the com_google_googletest rule in Abseil's WORKSPACE, downloaded the zip file, extracted it somewhere, copied everything except for the WORKSPACE file into the Abseil source tree. 2. Removed the com_google_googletest from Abseil's WORKSPACE. 3. Removed the strings @com_google_googletest and @com_google_absl from all BUILD* files. After that I could successfully bazel build --define absl=1 absl/... on Windows. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5640 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMJSMkukP7o75kTLNAAfcPpAaDYAbDCCks5utVLbgaJpZM4VWlmm> .

rongjiecomputer · 2018-11-09T14:36:53Z

Inspired by @laszlocsomor's solution:

In a WORKSPACE, specify Abseil and GoogleTest as [new_]local_repository or [new_]http_archive (so neither Abseil nor GoogleTest is the main repo __main__) (*), then run bazel test --define absl=1 @com_google_absl//absl/base/.... All tests pass.

I believe (*) is how most Bazel users consume Abseil and GoogleTest (main repo is user's own code). This solution should enable Abseil team to continue their work without breaking existing Abseil and GoogleTest users.

gennadiycivil · 2018-11-13T16:14:02Z

Thank you for this suggestion! I am a bit hazy for some reason.... could you please point me to the actual workspace file to look at? Thanks again G

…

On Fri, Nov 9, 2018 at 9:37 AM Loo Rong Jie ***@***.***> wrote: Inspired by @laszlocsomor <https://github.com/laszlocsomor>'s solution: In a WORKSPACE, specify Abseil and GoogleTest as [new_]local_repository or [new_]http_archive (so neither Abseil nor GoogleTest is the main repo __main__) (*), then run bazel test --define absl=1 @com_google_absl//absl/base/.... All tests pass. I believe (*) is how most Bazel users consume Abseil and GoogleTest. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5640 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMJSMrSmlWMgJYIrcwSO0LymG25SPtUuks5utZMZgaJpZM4VWlmm> .

rongjiecomputer · 2018-11-14T11:03:13Z

Sure thing! See https://github.com/rongjiecomputer/bazel-issue/tree/master/abseil

EDIT: fix cd command.

git clone --depth 1 https://github.com/rongjiecomputer/bazel-issue
cd bazel-issue/abseil
bazel test -c opt --define absl=1 @com_google_absl//absl/...

laszlocsomor · 2019-04-08T07:20:15Z

Sandboxing on Windows would solve this problem.

laszlocsomor · 2019-07-08T09:08:28Z

Lack of sandboxing is the culprit of this bug, and @rongjiecomputer is working on #5136 to address that.

Closing this in favor of #5136.

laszlocsomor · 2019-07-08T09:09:29Z

Actually, let's keep this open until sandoxing is done.

[Example failure](https://oss-fuzz-build-logs.storage.googleapis.com/log-8eabbac0-bb8f-4f90-a840-f23efe427e0e.txt) This only occurs on the fuzzers for some reason, not on Travis CI. Error is similar to bazelbuild/bazel#5640. Change spawn strategy to `sandboxed` to work around this. Not sure why it was `local` to begin with (other than a slight performance improvement). Tested locally to ensure this spawn strategy will work. ``` python infra/helper.py build_fuzzers --sanitizer address --engine libfuzzer --architecture x86_64 esp-v2 ``` Signed-off-by: Teju Nareddy <[email protected]>

github-actions · 2023-03-16T01:32:51Z

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 2.5 years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

github-actions · 2023-03-31T01:32:00Z

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!

dkelmer added platform: windows category: rules > C++ labels Jul 24, 2018

meteorcloudy self-assigned this Aug 8, 2018

meteorcloudy assigned dslomov and unassigned meteorcloudy Aug 13, 2018

laszlocsomor mentioned this issue Aug 29, 2018

C++,runfiles: rename sources to avoid conflict #6023

Closed

rongjiecomputer added a commit to rongjiecomputer/bazel-issue that referenced this issue Nov 14, 2018

Add abseil bazelbuild/bazel#5640 demo

3b00ee5

laszlocsomor mentioned this issue Jan 9, 2019

Include checking fails on windows for generated C header files (undeclared inclusion(s)) #7030

Closed

laszlocsomor added area-Windows Windows-specific issues and feature requests type: bug P3 We're not considering working on this, but happy to review a PR. (No assignee) and removed team-Rules-CPP Issues for C++ rules labels Apr 8, 2019

laszlocsomor closed this as completed Jul 8, 2019

laszlocsomor reopened this Jul 8, 2019

laszlocsomor changed the title ~~Bazel + MSVC C++ = missing dependency declarations~~ Bazel + MSVC C++ = missing dependency declarations [culprit #5136] Jul 8, 2019

jmillikin mentioned this issue Oct 10, 2019

//tests:m4_test fails to build on Windows due to incorrect header inclusion check jmillikin/rules_m4#5

Closed

meteorcloudy mentioned this issue Dec 2, 2019

Windows: Use of strip_include_prefix causes "missing dependency declarations" errors #6337

Closed

devjgm mentioned this issue Dec 13, 2019

[Flake] Windows build failed with segfault googleapis/google-cloud-cpp-spanner#1034

Closed

nareddyt mentioned this issue Mar 9, 2020

[esp-v2]: Fix broken builds by changing spawn strategy google/oss-fuzz#3485

Merged

meisterT unassigned dslomov May 14, 2020

collinbarnwell mentioned this issue Jun 1, 2020

--test_filter and --test_output flags cannot both be used at the same with with bazel test. #11529

Closed

philwo added the team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website label Jun 15, 2020

cellmigrate mentioned this issue Apr 12, 2022

作者您好，我试了官方hello world 以及 pose tracking都可以编译，但holistic_tracking_dll出现以下报错，搜了很久一直没解决，能麻烦帮忙看下不，谢谢！ HW140701/GoogleMediapipePackageDll#8

Closed

github-actions bot added the stale Issues or PRs that are stale (no activity for 30 days) label Mar 16, 2023

github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Mar 31, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bazel + MSVC C++ = missing dependency declarations [culprit #5136] #5640

Bazel + MSVC C++ = missing dependency declarations [culprit #5136] #5640

derekmauro commented Jul 19, 2018 •

edited

Loading

rongjiecomputer commented Jul 20, 2018

derekmauro commented Jul 20, 2018

rongjiecomputer commented Jul 20, 2018

rongjiecomputer commented Aug 8, 2018

meteorcloudy commented Aug 8, 2018

meteorcloudy commented Aug 8, 2018

dslomov commented Aug 8, 2018

meteorcloudy commented Aug 13, 2018

meteorcloudy commented Aug 29, 2018

meteorcloudy commented Aug 29, 2018

laszlocsomor commented Aug 29, 2018

laszlocsomor commented Aug 29, 2018 •

edited

Loading

meteorcloudy commented Aug 29, 2018

rongjiecomputer commented Aug 29, 2018

meteorcloudy commented Aug 29, 2018

laszlocsomor commented Aug 29, 2018 •

edited

Loading

laszlocsomor commented Aug 29, 2018 •

edited

Loading

laszlocsomor commented Aug 29, 2018

laszlocsomor commented Aug 29, 2018

meteorcloudy commented Aug 29, 2018

laszlocsomor commented Aug 29, 2018 •

edited

Loading

gennadiycivil commented Nov 9, 2018 via email

rongjiecomputer commented Nov 9, 2018 •

edited

Loading

gennadiycivil commented Nov 13, 2018 via email

rongjiecomputer commented Nov 14, 2018 •

edited

Loading

laszlocsomor commented Apr 8, 2019

laszlocsomor commented Jul 8, 2019

laszlocsomor commented Jul 8, 2019

github-actions bot commented Mar 16, 2023

github-actions bot commented Mar 31, 2023

Bazel + MSVC C++ = missing dependency declarations [culprit #5136] #5640

Bazel + MSVC C++ = missing dependency declarations [culprit #5136] #5640

Comments

derekmauro commented Jul 19, 2018 • edited Loading

Description of the problem / feature request:

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

What operating system are you running Bazel on?

What's the output of bazel info release?

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

Have you found anything relevant by searching the web?

rongjiecomputer commented Jul 20, 2018

derekmauro commented Jul 20, 2018

rongjiecomputer commented Jul 20, 2018

rongjiecomputer commented Aug 8, 2018

meteorcloudy commented Aug 8, 2018

meteorcloudy commented Aug 8, 2018

dslomov commented Aug 8, 2018

meteorcloudy commented Aug 13, 2018

meteorcloudy commented Aug 29, 2018

meteorcloudy commented Aug 29, 2018

laszlocsomor commented Aug 29, 2018

laszlocsomor commented Aug 29, 2018 • edited Loading

meteorcloudy commented Aug 29, 2018

rongjiecomputer commented Aug 29, 2018

meteorcloudy commented Aug 29, 2018

laszlocsomor commented Aug 29, 2018 • edited Loading

laszlocsomor commented Aug 29, 2018 • edited Loading

laszlocsomor commented Aug 29, 2018

laszlocsomor commented Aug 29, 2018

meteorcloudy commented Aug 29, 2018

laszlocsomor commented Aug 29, 2018 • edited Loading

gennadiycivil commented Nov 9, 2018 via email

rongjiecomputer commented Nov 9, 2018 • edited Loading

gennadiycivil commented Nov 13, 2018 via email

rongjiecomputer commented Nov 14, 2018 • edited Loading

laszlocsomor commented Apr 8, 2019

laszlocsomor commented Jul 8, 2019

laszlocsomor commented Jul 8, 2019

github-actions bot commented Mar 16, 2023

github-actions bot commented Mar 31, 2023

derekmauro commented Jul 19, 2018 •

edited

Loading

What's the output of `bazel info release`?

What's the output of `git remote get-url origin ; git rev-parse master ; git rev-parse HEAD` ?

laszlocsomor commented Aug 29, 2018 •

edited

Loading

laszlocsomor commented Aug 29, 2018 •

edited

Loading

laszlocsomor commented Aug 29, 2018 •

edited

Loading

laszlocsomor commented Aug 29, 2018 •

edited

Loading

rongjiecomputer commented Nov 9, 2018 •

edited

Loading

rongjiecomputer commented Nov 14, 2018 •

edited

Loading