Fix loading GDExtension dependencies on Android

[m4gr3d]

Update the Android gdextension loading logic so that it copies any specified library dependencies alongside the gdextension shared library.

Fixes #87785

[dsnopek]

Heh, just yesterday, I was just explaining to someone that the dependencies aren't used at all when loading a GDExtension, only in exporting. I guess that won't be true anymore, at least for Android. :-)

At a high-level, this looks good to me! I haven't done any testing.

[dsnopek]

Discussed at the GDExtension meeting, and the OS::open_dynamic_library() method is really starting to acquire a lot of arguments.

(This unrelated GDExtension PR also adds a new argument: #87117)

Perhaps we should consider having a more generic OS::open_dynamic_library() with the minimum of argument, and then another OS::open_gdextension_library() that takes lots of GDExtension-specific arguments, and the OS can do what is necessary for GDExtension? It should be OK to rework this since this method isn't exposed.

[m4gr3d]

Discussed at the GDExtension meeting, and the OS::open_dynamic_library() method is really starting to acquire a lot of arguments.

(This unrelated GDExtension PR also adds a new argument: #87117)

Perhaps we should consider having a more generic OS::open_dynamic_library() with the minimum of argument, and then another OS::open_gdextension_library() that takes lots of GDExtension-specific arguments, and the OS can do what is necessary for GDExtension? It should be OK to rework this since this method isn't exposed.

What about adding a gdextension specific argument which contains all the gdextension supplemental parameters and is nullptr by default for regular calls.
My concern with another method is possible confusion about what to use when since at its core a gdextension is a dynamic library.

[dsnopek]

I was imagining that the open_dynamic_library() would just do the low-level loading bits, and that open_gdextension_library() would probably call open_dynamic_library() (although, since both would be defined by the OS sub-class, they really could do it in whatever way made the most sense for the platform). It would only be GDExtension that would call open_gdextension_library() - any other code would call open_dynamic_library().

What about adding a gdextension specific argument which contains all the gdextension supplemental parameters and is nullptr by default for regular calls.

But, yes, that could work too! Are you imagining like a struct that has all the GDExtension info?

[m4gr3d]

But, yes, that could work too! Are you imagining like a struct that has all the GDExtension info?

Yeah somethink like a GDExtensionData similar to the pattern we have in other places like CustomExportData

[dsnopek]

While it isn't required to solve this now (because this is a purely internal API and we can change it at any time), I'd personally prefer if we made a struct (as discussed above) or some other strategy to reduce the number of arguments to OS::open_dynamic_library(). I don't think this is the last GDExtension-related piece of data that we're going to want to pass to this method.

[m4gr3d]

While it isn't required to solve this now (because this is a purely internal API and we can change it at any time), I'd personally prefer if we made a struct (as discussed above) or some other strategy to reduce the number of arguments to OS::open_dynamic_library(). I don't think this is the last GDExtension-related piece of data that we're going to want to pass to this method.

@dsnopek I've added the change into a second commit since the changes are orthogonal to each other, and to make it easier to review.

Let me know if you want me to collapse the commits together.

[dsnopek]

Thanks! I haven't tested it, but the code looks good to me :-)

[m4gr3d]

Thanks! I haven't tested it, but the code looks good to me :-)

I validated the fix in #87785 (comment)

[akien-mga]

Thanks!