Open dfreese opened 3 years ago
@dfreese the proposed solution may "regress" rust_binary
targets where -pie
is maybe what we want.
But building on that, I think one option is that we can use different action names depending on the crate type. I don't know the actions well enough to say if these can be mapped nicely to crate types though.
My solution is a bit "ad-hoc", adding code just after get_linker_and_args.
# remove the -pie flag if this is not a bin crate
if crate_info.type != "bin":
link_args = [arg for arg in link_args if arg != "-pie"]
@illicitonion, @hlopko any thoughts?
We, incorrectly or otherwise, been using --force-pic in our builds. This triggered a build failure with the following as a min repro:
WORKSPACE
BUILD
lib.rs (is empty)
When running with bazel 3.5.0, I see that:
Incidentally, we can still depend on a proc-macro target, and still build correctly. So I could, in theory, mark
fails_with_force_pic
with amanual
tag, and still use any code in it just fine.The only difference in the compilation step is that
-pie
is added to the link-args when --force-pic is enabled. This appears to be related to the use ofCPP_LINK_EXECUTABLE_ACTION_NAME
in get_linker_and_args(). Using CPP_LINK_NODEPS_DYNAMIC_LIBRARY_ACTION_NAME doesn't add-pie
, for example.@hlopko, given the type of extensions selected here, do you think that should be switch up based on crate type?