Establish a workflow for Libraries

[greenfox1505]

I have a handful of GDExt projects. I would like use these projects as dependencies. Right now, I have to remove the impl ExtensionLibrary from a given project before including it as a dependency. I'd like a way to allow one project to depend on multiple GodotRust GDExt projects without modifying the originals.

[aekobear]

I was able to get a set up like this working on the latest gdext.

• I have a "helper" library with crate-type = ["cdylib", "lib"] so that it can be added as a dependency.

• I have a main library with just crate-type = ["cdylib"]

• Both libraries are set up in the usual way with impl ExtensionLibrary in their source code

• The main library references the helper like so:

helper_library = { path = "../my_helper" }

• My godot project only has a main_library.gdextension

That last point is important- if you have a helper_library.gdextension, godot will try to register the same classes twice.

Is it possible that this set up is unsafe?

[aekobear]

Update: at some point my above set-up started to break when compiling using --release. I haven't been able to find a specific version of godot / gdext where this started happening. Debug builds still work perfectly. The error I get in a release build is:

= note: rust-lld: error: duplicate symbol: gdext_rust_init
          rust-lld: error: duplicate symbol: __cxa_thread_atexit_impl
          collect2: error: ld returned 1 exit status

The gdext_rust_init entry symbol can be customized, which fixes that conflict, but the __cxa_thread_atexit_impl is an unavoidable part of libc, as far as I can tell.

Ultimately, I was able to side-step the problem with a feature:

#[cfg(feature = "entry")]
#[gdextension]
unsafe impl ExtensionLibrary for MyLibrary {}

The only downside for this is that you need to enable the feature via command-line when building the library for use directly in godot (but nothing needs to be done when using it as a dependency, since the feature is off by default)

Maybe worth mentioning that the ability to distinguish between cdylib and lib at compilation could also solve this. But the issue seems unlikely to be solved any time soon because rustc generates both libs with a single compilation rust-lang/rust#20267