git hash in --build-id

[htuch]

Some projects, such as Envoy (https://github.com/lyft/envoy/) need the ability to set -Wl,--build-id=<git hash of workspace generating build> to encode the build ID in the .note.gnu.build-id ELF section.

It seems that Bazel uses this for hashing inputs or setting to a fixed value, based on the stamp option in cc_binary or --stamp on the CLI. Manually specifying a linkopt does not override, since this comes before the Bazel supplied --build-id on the command line.

What's the best practice for doing this today in Bazel?

I noticed #216, but this doesn't seem to reference setting the --build-id, it seems to be concerned with obtaining the build information.

CC @mattklein123 envoyproxy/envoy#415

[buchgr]

@mhlopko @ulfjack @lberki might know?

[buchgr]

@htuch could you please ask this question on stackoverflow using the bazel tag (so that other users can also benefit from an answer)? Bazel devs are monitoring SO and I am sure we'll find someone to answer your question there.

thanks so much!

[lberki]

We could remove --build-id=md5 from the linker command line (I haven't seen evidence that it was put in after careful thought...), but I can't think of a good way to convey the build stamp information to a linker option.

My best guess would be to use the the stamping data in a genrule to write a linker script, then reference that linker script on the linker command line, but I don't know if you can do the equivalent of --build-id=<stuff> that way.

[htuch]

@buchgr I think this is probably the right forum as we need to have some changes made to Bazel to get this to work I believe.

@lberki Yeah, if there was a way to suppress the --build_id=md5 that would be enough. I think we could use a genrule to generate a linker option file with the hash, and then supply to linkopts the option @generated_linker_option_filename.

We're going to need a workaround until Bazel gains this support, so I will investigate and update this issue.

[htuch]

@buchgr @lberki Thanks for sorting this. Do you know the Bazel release number and release date this will intercept?

[buchgr]

AFAIK it will be 0.5

[htuch]

I think there's a bit more to it than just the above commit. I tried writing a genrule to produce a file build_id_options that can be supplied by @build_id_options in linkopts. Bazel gets confused by linkopts beginning with @, treating them as labels that it needs to resolve rather than options to pass to the linker.

It would probably be most convenient if we can just add something like --build-id=$(BUILD_SCM_REVISION) to the linker. But this variable isn't available under make variable substitution today.

Can we reopen this issue to get to a working implementation?

[htuch]

Friendly ping to @buchgr to reopen. Thanks.

[lberki]

Here's the plan: we are going to add a linker_param_files attribute to cc_binary which will tell Bazel to add options in it to the linker command line.

Then you can write a genrule that takes the commit hash out of the linkstamp information (stable-status.txt), writes -Wl,--build-id=<commithash> to a file, then add that to this new attribute on cc_binary.

LGTY?

[htuch]

@lberki LGTM,thanks. One question; what will happen to other linker params that are inserted by CROSSTOOLS or via the Bazel internally? I'm kind of worried we might still see the --build_id=md5 injected prior to our linker options?

[lberki]

I was hoping that later --build-id options supersede former ones. Isn't that the case?

[htuch]

Yeah, seems likely but needs verification. Ideally we have some Bazel test for this functionality that demonstrates this.

[hlopko]

Since 724706b bazel doesn't emit --build-id=md5

[helenalt]

@oquenchil is this issue resolved with the additional_linker_inputs attribute?

[oquenchil]

I'm still working on adding the additional_linker_inputs attribute but Harvey can use a workaround meanwhile which is ugly but does the job for now.

[htuch]

We're tracking this on the Envoy side in envoyproxy/envoy#2625. We need to find someone with cycles to validate the new Bazel native solutions, CC: @jmillikin-stripe.