-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Windows: cc_binary has multiple output artifacts when depending on DLLs #8707
Labels
area-Windows
Windows-specific issues and feature requests
P2
We'll consider working on this in future. (Assignee optional)
platform: windows
team-OSS
Issues for the Bazel OSS team: installation, release processBazel packaging, website
type: bug
Comments
@meteorcloudy Great! Thanks for fixing this! What release do you expect this fix will make it into? |
This will be in next month's release (0.28.0) ;) |
siberex
pushed a commit
to siberex/bazel
that referenced
this issue
Jul 4, 2019
Bazel copies dynamic libraries to the binary's directory so that it's available at runtime. Before this change, all runtime dynamic libraries are added into the default output group, this is bad because it makes the target name (eg. //:foo.dll) refer to multiple artifacts. In this change, we are having a separate output group (runtime_dynamic_libraries) for them. Fixes bazelbuild#8707 RELNOTES: The runtime dynamic libraries are no longer in default output group of cc_binary. PiperOrigin-RevId: 254931976
FYI, 0.28.0 has 210428c but not the fix, I'm asking for a cherry-pick into 0.28.1. |
irengrig
pushed a commit
to irengrig/bazel
that referenced
this issue
Jul 15, 2019
Bazel copies dynamic libraries to the binary's directory so that it's available at runtime. Before this change, all runtime dynamic libraries are added into the default output group, this is bad because it makes the target name (eg. //:foo.dll) refer to multiple artifacts. In this change, we are having a separate output group (runtime_dynamic_libraries) for them. Fixes bazelbuild#8707 RELNOTES: The runtime dynamic libraries are no longer in default output group of cc_binary. PiperOrigin-RevId: 254931976
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
P2
We'll consider working on this in future. (Assignee optional)
platform: windows
team-OSS
Issues for the Bazel OSS team: installation, release processBazel packaging, website
type: bug
In a normal case, building
//foo.dll
will only generate one output artifactfoo.dll
in the default output group.When the cc_binary depends on an dll, for example:
In this case, Bazel uses
bar.lib
atfoo.dll
's linking time and copiesbar.dll
to the directory offoo.dll
in order to make it available at runtime. But, Bazel also addsbar.dll
to the default output group offoo.dll
, which is problematic because when users try to referencefoo.dll
via//bar:foo.dll
, it actually have more than one output artifact. This could be very confusing and there is no good way to distinguish the main output (foo.dll
) from its dll dependencies (bar.dll
).One way to solve this is to add all DLL dependencies to a separate output group (eg.
runtime_dynamic_libraries
) and make sure the default output group of a cc_binary will always have a single artifact.The text was updated successfully, but these errors were encountered: