Supporting multiple C API versions

Problem: I am developing a Rust integration layer for a vendor C library and I want to support multiple versions of that C library.

Simple example: C library V1 exposes "get_name" and V2 exposes "get_name2". From a rust perspective the signature is roughly: fn get_name() -> String... but the C bindings are different because uses an output char[100] and the other uses an output char **. There are about 300 C functions in total that are exposed in the API and about 30 of them are different between V1 and V2.

I know that I can use bindgen to create the different bindings but I am curious how others have tried to solve this problem? Would you generate two different crates of C bindings, one for V1 and one for V2 and then use cargo/features to pull in the correct one?
Would you just use cfg attributes to do conditional compilation in a crate that depends on the C level bindings? Or some other approach?

I don't fully understand the problem. Which of the following is true:

  1. your Rust API only needs to support functions supported in intersect(c_api_v1, c_api_v2)

  2. your Rust API needs some toggle that lets the user use functions in
    intersect(c_api_v1, c_api_v2),
    set_minus(c_api_v1, c_api_v2),
    set_minus(c_api_v2, c_api_v1),

api_v2 is a superset of api_v1 but in some cases has different method names from the same functionality - see the get_name vs get_name2 example in my original post.
I want to hide this low-level implementation detail of the C API from my higher level Rust programs.

Is this case (1) or case (2) ?