Multiple definition error across multiple include_cpp calls

[VirxEC]

Expected Behavior

This shouldn't crash and the symbols should be properly mangled so they don't conflict across include_cpp calls.

Actual Behavior

error: linking with `cc` failed: exit status: 1
  |
  = note: command omitted for brevity
  = note: /usr/bin/ld: /autocxx-err/target/debug/build/autocxx-err-1cd1cc8230fa4802/out/libmultifileerror.a(172f5ed9fec53081-gen2.o): in function `cxxbridge1$new_autocxx_autocxx_wrapper':
          /autocxx-err/target/debug/build/autocxx-err-1cd1cc8230fa4802/out/autocxx-build-dir/cxx/gen2.cxx:136: multiple definition of `cxxbridge1$new_autocxx_autocxx_wrapper'; /autocxx-err/target/debug/build/autocxx-err-1cd1cc8230fa4802/out/libmultifileerror.a(172f5ed9fec53081-gen0.o):/autocxx-err/target/debug/build/autocxx-err-1cd1cc8230fa4802/out/autocxx-build-dir/cxx/gen0.cxx:136: first defined here
          collect2: error: ld returned 1 exit status

It should be noted that the name of the files (e.x. gen2.cxx, gen0.cxx) is consistent after running cargo clean and then recompiling.

Steps to Reproduce the Problem

src/thing.h:

#pragma once

struct Thing {
    float id;

    Thing(float id) : id(id) {}
};

src/item.h:

#pragma once

struct Item {
    float id;

    Item(float id) : id(id) {}
};

src/main.rs:

use autocxx::WithinUniquePtr;

autocxx::include_cpp! {
    #include "thing.h"
    name!(thing)
    safety!(unsafe)
    generate!("Thing")
}

autocxx::include_cpp! {
    #include "item.h"
    name!(item)
    safety!(unsafe)
    generate!("Item")
}

fn main() {
    let thing = thing::Thing::new(15.).within_unique_ptr();
    let item = item::Item::new(15.).within_unique_ptr();
}

src/build.rs:

use autocxx_build::Builder;
use miette::Result;

fn main() -> Result<()> {
    Builder::new("src/main.rs", ["src/"])
        .build()?
        .warnings(false)
        .compile("multifileerror");

    println!("cargo:rerun-if-changed=src/lib.rs");

    Ok(())
}

Specifications

• Version: 0.23.1
• Platform: Ubuntu 22.10

[VirxEC]

If this is solved, it could potential serve as a work-around to #486

[VirxEC]

I might have a simple solution for this

[adetaylor]

Thanks - see comments on pull request.