-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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.
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
Runtime exception on Windows when evaluating BazelCcProtoAspect
nodes
#6171
Labels
area-Windows
Windows-specific issues and feature requests
team-OSS
Issues for the Bazel OSS team: installation, release processBazel packaging, website
untriaged
Comments
I can reproduce the above example with Windows 10, |
katre
pushed a commit
that referenced
this issue
Oct 16, 2018
The MSYS gcc and MINGW gcc toolchains do support linking against shared library. So the precondition check should be disabled for them. CcProtoAspect.java should set emitInterfaceSharedObjects to true when the toolchain supports interface shared library. Fixes #6171 Fixes #6292 Fixes #6169 RELNOTES: None PiperOrigin-RevId: 216258674
katre
pushed a commit
that referenced
this issue
Oct 17, 2018
The MSYS gcc and MINGW gcc toolchains do support linking against shared library. So the precondition check should be disabled for them. CcProtoAspect.java should set emitInterfaceSharedObjects to true when the toolchain supports interface shared library. Fixes #6171 Fixes #6292 Fixes #6169 RELNOTES: None PiperOrigin-RevId: 216258674
aehlig
pushed a commit
that referenced
this issue
Oct 23, 2018
The MSYS gcc and MINGW gcc toolchains do support linking against shared library. So the precondition check should be disabled for them. CcProtoAspect.java should set emitInterfaceSharedObjects to true when the toolchain supports interface shared library. Fixes #6171 Fixes #6292 Fixes #6169 RELNOTES: None PiperOrigin-RevId: 216258674
katre
pushed a commit
that referenced
this issue
Oct 23, 2018
The MSYS gcc and MINGW gcc toolchains do support linking against shared library. So the precondition check should be disabled for them. CcProtoAspect.java should set emitInterfaceSharedObjects to true when the toolchain supports interface shared library. Fixes #6171 Fixes #6292 Fixes #6169 RELNOTES: None PiperOrigin-RevId: 216258674
katre
pushed a commit
that referenced
this issue
Oct 23, 2018
The MSYS gcc and MINGW gcc toolchains do support linking against shared library. So the precondition check should be disabled for them. CcProtoAspect.java should set emitInterfaceSharedObjects to true when the toolchain supports interface shared library. Fixes #6171 Fixes #6292 Fixes #6169 RELNOTES: None PiperOrigin-RevId: 216258674
aehlig
pushed a commit
that referenced
this issue
Oct 24, 2018
The MSYS gcc and MINGW gcc toolchains do support linking against shared library. So the precondition check should be disabled for them. CcProtoAspect.java should set emitInterfaceSharedObjects to true when the toolchain supports interface shared library. Fixes #6171 Fixes #6292 Fixes #6169 RELNOTES: None PiperOrigin-RevId: 216258674
katre
pushed a commit
that referenced
this issue
Oct 24, 2018
The MSYS gcc and MINGW gcc toolchains do support linking against shared library. So the precondition check should be disabled for them. CcProtoAspect.java should set emitInterfaceSharedObjects to true when the toolchain supports interface shared library. Fixes #6171 Fixes #6292 Fixes #6169 RELNOTES: None PiperOrigin-RevId: 216258674
aehlig
pushed a commit
that referenced
this issue
Oct 29, 2018
The MSYS gcc and MINGW gcc toolchains do support linking against shared library. So the precondition check should be disabled for them. CcProtoAspect.java should set emitInterfaceSharedObjects to true when the toolchain supports interface shared library. Fixes #6171 Fixes #6292 Fixes #6169 RELNOTES: None PiperOrigin-RevId: 216258674
philwo
added
the
team-OSS
Issues for the Bazel OSS team: installation, release processBazel packaging, website
label
Jun 15, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area-Windows
Windows-specific issues and feature requests
team-OSS
Issues for the Bazel OSS team: installation, release processBazel packaging, website
untriaged
Description of the problem / feature request:
Build causes a RuntimeException on Windows; this appears to happen when one
proto_library
rule depends on anotherproto_library
rule.Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Command
bazel.exe build //some_proto/...
Output
WORKSPACE
some_proto/BUILD
some_proto/foo.proto
some_other_proto/BUILD
some_other_proto/bar.proto
What operating system are you running Bazel on?
Windows Server 2012 R2 Datacenter
What's the output of
bazel info release
?release 0.17.1
Have you found anything relevant by searching the web?
I seem to be hitting this precondition which was introduced in this commit.
Symptoms are similar to #6169, and this may be a dupe. However:
proto_library
rules that depend on each other, not protoc itself.Any other information, logs, or outputs that you want to share?
bazel.exe build //some_other_proto/...
is fine); asking bazel to analyze aproto_library
with anotherproto_library
rule in itsdeps
attribute seems to cause the issue.The text was updated successfully, but these errors were encountered: