Add simple C++ to Rust interop example with Makefile build script

[TG199]

Add example demonstrating C++ calling Rust via C ABI and Makefile

[thunderseethe]

Hello I'm Ethan. One of the co-mentors with Outreachy. It looks like this successfully calls Rust from C++ which is great. It's often the case in interop that we need to both call Rust from C++ and call C++ from Rust. What would it take to extend this example so that our Rust code calls into C++?

[TG199]

Hi @thunderseethe To support calling C++ from Rust, my understanding is that I would need to define a C++ function (exposed with C ABI) and then declare it in Rust using an extern block, calling it via unsafe.

I’m thinking of extending the current example with a small C++ function (e.g. multiply) and invoking it from the Rust code to demonstrate bidirectional interop.

[teor2345]

Here's how to fix the CI failures

[teor2345]

Part of CI is failing because the formatting is slightly different to standard, try running cargo fmt --all

[teor2345]

Part of CI is failing because of linker order. Most linkers expect all functions provided early on the command line, and the users of those functions listed later.

There's a circular dependency here, because:

• main.cpp needs to be listed first so it can find add
• but rustlib needs to be listed first so it can fund multiply

This can be fixed using library groups:
https://stackoverflow.com/questions/9380363/resolving-circular-dependencies-by-linking-the-same-library-twice

[TG199]

Hi @teor2345 I've added --start-group/--end-group to the Makefile to handle the circular dependency for the full build. But CI jobs 1 and 2 also fail because they run cargo build and cargo test on the Rust crate alone, where multiply isn't available. Should I add a build.rs that compiles the C++ code so the Rust crate can build standalone, or is there a better way to structure this?

[teor2345]

I've added --start-group/--end-group to the Makefile to handle the circular dependency for the full build. But CI jobs 1 and 2 also fail because they run cargo build and cargo test on the Rust crate alone, where multiply isn't available. Should I add a build.rs that compiles the C++ code so the Rust crate can build standalone, or is there a better way to structure this?

Huh, yeah, that is an issue.

For library builds, all the symbols don't need to be defined, so you're fine not having multiply.

For test builds, it's a binary, so it needs all the symbols. Your options are:

• add a build.rs (possibly that only runs during tests), to build the C++ multiply
• add a Rust version of multiply, that is #[cfg(test)], so it only builds during tests
• replace the call to multiply during tests with the Rust * operation (using #[cfg(not(test))] for the current call)

I think the last option is the simplest, but I'm happy to guide you through whichever one you want.

[TG199]

Ok, cool. I'd like to try the build.rs approach since it feels most relevant to the project's focus on build system integration. I'd appreciate guidance on that if you're willing!

[teor2345]

Thank you, this is a useful example of circular dependencies in code and tests.