Building shared objects: is there any way to stop cc_libraries from generating non-PIC static libraries?

[ahyangyi]

Here's an example:

cc_library(name="foo", srcs = [...], hdrs = [...])
cc_library(name="bar", srcs = [...], hdrs = [...])
cc_library(name="baz", deps=[":foo", ":bar"], alwayslink = 1, srcs = [...], hdrs = [...])
cc_binary(name="libbaz_release.so", deps=[":baz"], linkshared=1)

which is what I believe the currently recommended idiom for building a shared object.

Here's the question:
if I type bazel build //...:all, all source code in libraries foo, bar and baz will be built twice, once with -fPIC and once without. However, since I have no actual use with the non-fPIC versions, such building time and energy is wasted.

Is there some way to fix this?

Thanks.

[ahyangyi]

I also noticed that Bazel has the notion of an implicit output of a rule. Sadly, currently .pic.a is implicit, but .a is explicit. So in my case that mechanism doesn't help much.

[ahyangyi]

Hey, I just noticed that under fastbuild or dbg mode Bazel seems to always build .pic.o and generate .a from these .pic.o files instead of calling them .pic.a. This behavior is different from under opt. So the current behavior is really even more complex than I thought.

You really want to document these when it's complex like this :O

[calpeyser]

You can disable PIC in your CROSSTOOL, if you'd like. There's a needsPic field.

re: implicit outputs, we're trying to remove them across the board for c++. We want to make the c++ rules suitable for other platforms, and implicit outputs produce platform-specific artifacts. For example, a Windows cc_library would produce a .lib, not a .a.

Sorry you've had to wait so long for me to engage on this. And yes, we certainly need to more broadly document the cc rules

[ahyangyi]

@calpeyser That sounds nice. I guess disabling needsPic and adding -fpic as the default compiler option should work for me.

[steven-johnson]

Adding fuel to the fire here: in -c opt mode, a library produces both ".a" and ".pic.a" outputs; if you have a genrule downstream that needs to consume this output, this makes it hard to do so, since you need to use $(location :foo) for dbg and fast, but $(locations :foo) with some filtering for opt...

[hlopko]

Is there anything that needs to be done here? Feel free to reopen if yes. I guess Steven's point is valid, so if you still think this should be fixed, please open a separate issue. Thank you everybody!