Objects produced with cargo_build_script may be linked in cc_* targets. For this to succeed, the options for building with a cargo build script and with cc_* should be (mostly) the same.
When using a cargo_build_script that compiles a C++ object, the env and command line arguments from the cc_toolchain are not forwarded to cargo_build_script_runner/bin.rs.
(This is in continuation of my comments here #969 (comment))
PR coming soon.
Example
Suppose the cc_toolchain defines -D_GLIBCXX_USE_CXX11_ABI=0. Now suppose we use a cargo_build_script that compiles a cc_library that has in its sources:
void f(const std::string& str);
If we now try to link this library in a cc_binary which calls f, we will get a link-time error for undefined reference to f. Upon inspecting the symbols of the library produced by cargo_build_script we can find f. However, upon further inspection, the mangling of the parameter for the function is different - std::__cxx11:basic_string..., whereas the cc_binary looks for std::basic_string....
Objects produced with
cargo_build_scriptmay be linked incc_*targets. For this to succeed, the options for building with a cargo build script and withcc_*should be (mostly) the same.When using a
cargo_build_scriptthat compiles a C++ object, the env and command line arguments from thecc_toolchainare not forwarded tocargo_build_script_runner/bin.rs.(This is in continuation of my comments here #969 (comment))
PR coming soon.
Example
Suppose the
cc_toolchaindefines-D_GLIBCXX_USE_CXX11_ABI=0. Now suppose we use acargo_build_scriptthat compiles acc_librarythat has in its sources:If we now try to link this library in a
cc_binarywhich callsf, we will get a link-time error forundefined reference to f. Upon inspecting the symbols of the library produced bycargo_build_scriptwe can findf. However, upon further inspection, the mangling of the parameter for the function is different -std::__cxx11:basic_string..., whereas the cc_binary looks forstd::basic_string....