Skip to content

Conversation

@adetaylor
Copy link
Collaborator

In some non-Cargo build configurations, the Rust and C++ side of cxx
bindings may end up in different binaries. In some environments,
this requires symbols to be explicitly exported using
__declspec(dllexport) or similar directives. A previous change added
the --cxx-impl-annotations switch on the cxx-gen command line tool,
providing the opportunity to specify such directives for dynamically
generated parts of the cxx bindings.

It turns out to be similarly useful to export symbols from cxx.cc.
This change adds a pair of preprocessor symbols which folks can define
if they need to export these symbols too.

In some non-Cargo build configurations, the Rust and C++ side of cxx bindings may end up in different binaries. In some environments, this requires symbols to be explicitly exported using __declspec(dllexport) or similar directives. A previous change added the --cxx-impl-annotations switch on the cxx-gen command line tool, providing the opportunity to specify such directives for dynamically generated parts of the cxx bindings. It turns out to be similarly useful to export symbols from cxx.cc. This change adds a pair of preprocessor symbols which folks can define if they wish to export these symbols too.
No functional changes.
aarongable pushed a commit to chromium/chromium that referenced this pull request Mar 17, 2022
This is a version of dtolnay/cxx#1025 backported to the version of cxx which we currently use, plus associated GN changes to trigger that behavior. Purpose of this change: The Rust cxx interop tool produces both Rust and C++ side code for its bindings. It also has fixed C++ code for some of its interop types (e.g. the C++ representation of a Rust string). In most cases, all of this ends up in the same binary, but in debug component builds a test executable may have Rust code which needs to use thse symbols from (for instance) libbase.so. We already previously exported the symbols for dynamically generated bindings code; we now export the symbols for the fixed C++ code too. The patch within this change should be removed if/when dtolnay/cxx#1025 is accepted upstream and we have rolled cxx to include it. Bug: 1287545 Change-Id: I6a0f76fcf6afb36718d5e939c797e7988826bad1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3531194 Reviewed-by: danakj <danakj@chromium.org> Commit-Queue: Adrian Taylor <adetaylor@chromium.org> Cr-Commit-Position: refs/heads/main@{#982195}
zeng450026937 pushed a commit to zeng450026937/build that referenced this pull request Mar 18, 2022
This is a version of dtolnay/cxx#1025 backported to the version of cxx which we currently use, plus associated GN changes to trigger that behavior. Purpose of this change: The Rust cxx interop tool produces both Rust and C++ side code for its bindings. It also has fixed C++ code for some of its interop types (e.g. the C++ representation of a Rust string). In most cases, all of this ends up in the same binary, but in debug component builds a test executable may have Rust code which needs to use thse symbols from (for instance) libbase.so. We already previously exported the symbols for dynamically generated bindings code; we now export the symbols for the fixed C++ code too. The patch within this change should be removed if/when dtolnay/cxx#1025 is accepted upstream and we have rolled cxx to include it. Bug: 1287545 Change-Id: I6a0f76fcf6afb36718d5e939c797e7988826bad1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3531194 Reviewed-by: danakj <danakj@chromium.org> Commit-Queue: Adrian Taylor <adetaylor@chromium.org> Cr-Commit-Position: refs/heads/main@{#982195} NOKEYCHECK=True GitOrigin-RevId: 3b659d0f18bf8f08354a8c35a25b51e542eed659
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

1 participant