Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge conflict between GDNative and Android plugins shared libraries #53232

Open
m4gr3d opened this issue Sep 29, 2021 · 4 comments
Open

Merge conflict between GDNative and Android plugins shared libraries #53232

m4gr3d opened this issue Sep 29, 2021 · 4 comments

Comments

@m4gr3d
Copy link
Contributor

m4gr3d commented Sep 29, 2021

Godot version

3.3.3.stable

System information

Android

Issue description

We need to surface to the user when GDNative addons have similarly named shared libraries as the Android plugins included in the project.

As of Godot 3.3.3, the GDNative addons silently override the shared libraries provided by the Android plugins which can lead to invalid builds and user confusion.

I'm not sure there's an automatic way we can resolve these merge conflicts, and so I'm leaning toward surfacing the issue to the user for a manual resolution (e.g: deleting the invalid shared libraries).

Steps to reproduce

Load a Godot project which has GDNative addon(s) and Android plugin(s) with similarly named shared libraries and attempt to export the project.

Minimal reproduction project

No response

@m4gr3d
Copy link
Contributor Author

m4gr3d commented Sep 29, 2021

I plan to update the way we handle Android plugins (aar binary) within the Godot Editor in the near future (proposal coming soon).
As part of that work, I'll be adding logic to detect when included GDNative addons and Android plugins have conflicting shared libraries.

@akien-mga akien-mga added the bug label Sep 29, 2021
@m4gr3d
Copy link
Contributor Author

m4gr3d commented Sep 29, 2021

@BastiaanOlij
Copy link
Contributor

Michael from VRWorkout is hanging out for this, he has already moved to 3.3 (or maybe even 3.4) because he's using various added features and is thus stuck on VrApi. Not knowing exactly his configuration I'm not sure why he's not using the OpenXR plugin with just the native libraries and only using AAR for the other plugins he uses or if he's stuck on some other combination of conflicts that this causes.

All in all though, moving forward this is something to solve seeing for OpenXR cross platform development we're going to have the full plugin installed in addons even if a custom build setup is used for Android deployment and we can't simply remove parts of the addons folder if they clash with deploying the binaries through AAR as it will break deployment on other platforms.
The files supplied through the AAR should take precedence over the files in the plugin folder.

@akien-mga
Copy link
Member

Is this still relevant in 3.x? I assume it's not for 4.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants