Skip to content
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

Closed
meteorcloudy opened this issue Jun 24, 2019 · 5 comments
Closed
Assignees
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
Copy link
Member

cc_binary(
  name = "foo.dll",
  srcs = ["foo.cc"],
)

In a normal case, building //foo.dll will only generate one output artifact foo.dll in the default output group.

When the cc_binary depends on an dll, for example:

cc_import(
  name = "bar",
  shared_library = "bar.dll",
  interface_library = "bar.lib",
)

cc_binary(
  name = "foo.dll",
  srcs = ["foo.cc"],
  deps = ["//:bar"],
)

In this case, Bazel uses bar.lib at foo.dll's linking time and copies bar.dll to the directory of foo.dll in order to make it available at runtime. But, Bazel also adds bar.dll to the default output group of foo.dll, which is problematic because when users try to reference foo.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.

@meteorcloudy meteorcloudy added type: bug P2 We'll consider working on this in future. (Assignee optional) platform: windows area-Windows Windows-specific issues and feature requests labels Jun 24, 2019
@meteorcloudy meteorcloudy self-assigned this Jun 24, 2019
@meteorcloudy
Copy link
Member Author

meteorcloudy commented Jun 24, 2019

FYI @baskus @brills

@baskus
Copy link

baskus commented Jun 25, 2019

@meteorcloudy Great! Thanks for fixing this!

What release do you expect this fix will make it into?

@meteorcloudy
Copy link
Member Author

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
@meteorcloudy
Copy link
Member Author

@baskus @siberex 2260b97 fixed a bug caused by 210428c , if you're cherry-picking 210428c, you should also need this fix.

@meteorcloudy
Copy link
Member Author

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
@philwo 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 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
Projects
None yet
Development

No branches or pull requests

3 participants