Unexpected C++ re-linking

[patrick...@spacex.com]

We've been noticing that dynamically linked c++ executables are re-linked when we don't expect them to be. Header changes to libraries should trigger re-linking and do.​ However, it is not clear why source-only changes should require transitive downstream dependencies to re-link, though it seems they actually do so during a Bazel build. I have not found a reference in the documentation, nor any threads addressing this topic. We would appreciate clarification on whether this behavior is intended or configurable.

To demonstrate this behavior, we can use the cpp-tutorial/stage2 hello-world application in the bazel tutorials: https://github.com/bazelbuild/examples/
Make the binary dynamic by adding "linkstatic=0" to the cc_binary rule. Change the string in hello-greet.cc, and the binary will re-link upon building //main:hello-world.

Subcommands show:
SUBCOMMAND: # //main:hello-greet [action 'Compiling main/hello-greet.cc']
SUBCOMMAND: # //main:hello-greet [action 'Linking main/libhello-greet.so']
SUBCOMMAND: # //main:hello-world [action 'Linking main/hello-world']

Explanations of rebuilds show:
Executing action 'BazelWorkspaceStatusAction stable-status.txt': unconditional execution is requested.
Executing action 'Compiling main/hello-greet.cc': One of the files has changed.
Executing action 'Linking main/libhello-greet.so': One of the files has changed.
Executing action 'SolibSymlink _solib_k8/libmain_Slibhello-greet.so': One of the files has changed.
Executing action 'Linking main/hello-world': One of the files has changed.

Since hello-greet.h wasn't changed, I think chain should have been able to stop after re-linking the shared library. This was done with 0.7.0

We'd appreciate your thoughts.​

[Marcel Hlopko]

Hi Patrick,

we need to rerun the linking to correctly detect errors (e.g. what if your change removed a symbol).

Internally we have a tool that generates interface shared libraries (in the codebase you'll see references to 'ifso') from normal shared libraries. This is unfortunately not open sourced, because the elf-parsing library we use for the tool is not open sourced. If you provide the tool, you can teach bazel to make use of interface libraries. The trick is that even though shared library changes, interface library doesn't always have to. And binaries only depend on the interface libraries for linking, and will be relinked only when interface libraries change.

So if this is critical to you, you'll have to build the ifso builder yourself. I can help with setting it up with bazel.

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/d3d1a9aa-b058-4c5a-b6f5-45bf18b4237b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

-- 

Marcel Hlopko | Software Engineer | hlo...@google.com | 

Google Germany GmbH | Erika-Mann-Str. 33  | 80636 München | Germany | Geschäftsführer: Geschäftsführer: Paul Manicle, Halimah DeLaine Prado | Registergericht und -nummer: Hamburg, HRB 86891

[patrick...@spacex.com]

Thanks for the explanation, Marcel. That's unfortunate, but it's is good to know there's a possible route available to us.

I've opened https://github.com/bazelbuild/bazel/issues/4135 as a feature request, and to provide some documentation of the current behavior.

[Marcel Hlopko]

Thanks Patrick, I'll ping the bug if anything reg. ifso builder open-sourcing changes.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/a8aafcc0-2765-4e93-ba91-756a83d22f2b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.