On Linux, favor local symbols when loading a shared library

[dsnopek]

Fixes #82812

Myself and the reporter of that issue, are seeing a strange situation where a GDExtension will use a class defined by the engine with the same name, rather than the class defined in the GDExtension.

Passing RTLD_DEEPBIND to dlopen() when loading the GDExtension seems to fix it in my testing!

About RTLD_DEEPBIND, the man page says:

Place the lookup scope of the symbols in this shared object ahead of the global scope. This means that a self-contained object will use its own symbols in preference to global symbols with the same name contained in objects that have already been loaded.

I'm definitely not an expert on platform-level stuff, so I don't know if this flag has any limitations or caveats associated with it.

Downloading pre-compiled binaries:

1. Login into github
2. Click the "checks" tab of this PR
3. On the right there's an "artifacts" button.
4. Download the appropriate build for your plaform

[bruvzg]

That's likely won't build on macOS and BSDs, the function is overridden on macOS but generic Unix code is still built.

[dsnopek]

Ah, ok, so should I override it in OS_LinuxBSD? Or just add an #ifdef in OS_Unix (it'd still need an #ifdef in OS_LinuxBSD so BSD doesn't use it)?

[dsnopek]

Or, actually, I wonder if this problem also affects GDExtensions on MacOS and *BSD? If so, then perhaps the other solution discussed on the issue (building with -fvisibility=hidden) would be the better way to go?

[bruvzg]

Ah, ok, so should I override it in OS_LinuxBSD?

I would probably add something like:

#ifndef RTLD_DEEPBIND
#define RTLD_DEEPBIND 0
#endif

[dsnopek]

The OP on issue #82812 confirmed that this fixed their problem as well

[bruvzg]

I can't reproduce the issue on macOS.

As far as I can tell, adding RTLD_DEEPBIND seems fine.

[akien-mga]

Thanks!