Fix #2406: use codegen option link-args to forward user_link_flags in bindgen.

[ghost]

This commit fixes issue #2406 by using the link-args codegen option of rustc:

-C
link-args=<user_link_flags>

where <user_link_flags> are the flags from the user_link_flags field of LinkerInput.

[UebelAndre]

Thanks!

[tidefield]

@UebelAndre I think this will only work if we link using rustc. If we run the linker directly (i.e. enabling experimental_use_cc_common_link, it won't work because the linker doesn't understand -C link-args. Only rustc understands -C link-args=<args> and passes <args> to the linker.

[UebelAndre]

Dang, good catch! Any suggestions on how to deal wit this?

cc @thb-sb

[ghost]

Ho, I haven't though of cc_common.link…
So basically, the solution would be to use the former if cc_common.link is used, otherwise the latter.
I'll try something to fix this.
Thank you @daivinhtran for reporting this corner case!

[tidefield]

Another subtle thing I notice in the example provided in #2406 is that rust_bindgen_library shouldn't trigger any linking (neither calling rustc with -C linker=<> -C link-args or a separate linking action) because the macro (which creates rust_library -> rust_bindgen) only produces an rlib, not a shared library or binary.

Is

# BUILD
load("@rules_rust//bindgen:defs.bzl", "rust_bindgen_library")                    
                                                                                 
cc_library(                                                                      
    name = "foo",                                                                
    srcs = ["foo.c"],                                                            
    hdrs = ["foo.h"],                                                            
    linkopts = ["-framework", "Security"],                                       
)                                                                                
                                                                                 
rust_bindgen_library(                                                            
    name = "foo_bindgen",                                                        
    cc_lib = ":foo",                                                             
    header = "foo.h",                                                            
)

all you need to reproduce the error with the link flags? Or is there another downstream target like rust_binary that requires linking?

[tidefield]

IIUC, the right fix isn't simply

1. If use cc_common.link, don't use -C link-args=<link flags>
2. Else, use -C link-args
   at the bindgen rule level.

IMO the right fix is to keep link flags without -C link-args= as before.

At the downstream (shared library or binary) targets which run linking, we then decide whether to add -C link-args or not based on the setting of experimental_use_cc_common_link. We already have this logic implemented.

[tidefield]

More context: In

rules_rust/rust/private/rustc.bzl

Lines 998 to 1013 in 90e4505

	if ("link" in emit and crate_info.type not in ["rlib", "lib"]) or rustdoc:
	# Rust's built-in linker can handle linking wasm files. We don't want to attempt to use the cc
	# linker since it won't understand.
	compilation_mode = ctx.var["COMPILATION_MODE"]
	if toolchain.target_arch != "wasm32":
	if output_dir:
	use_pic = _should_use_pic(cc_toolchain, feature_configuration, crate_info.type, compilation_mode)
	rpaths = _compute_rpaths(toolchain, output_dir, dep_info, use_pic)
	else:
	rpaths = depset()
	ld, link_args, link_env = get_linker_and_args(ctx, attr, crate_info.type, cc_toolchain, feature_configuration, rpaths, rustdoc)
	env.update(link_env)
	rustc_flags.add(ld, format = "--codegen=linker=%s")
	rustc_flags.add_joined("--codegen", link_args, join_with = " ", format_joined = "link-args=%s")

.

The rules' implementation already ignore linking when building rlib and lib. rust_bindgen_library produces rlib which shouldn't involve any link flags at all.

[tidefield]

I filed #2413 to triage the issue.