dlopen: program symbols override the one used by library

[leorize]

The snippet attached below describe this problem.

How to run:

$ gcc -o dl dl.c
$ gcc -DLIBRARY -shared -o dl.so dl.c
$ LIBRARY_PATH="$PWD:$LIBRARY_PATH" ./dl

Expected:

from library

Got:

from program

The snippet has been tested on Linux, OpenBSD, FreeBSD and so far only Haiku exhibit this behavior.

[leorize]

As a walkaround, the binary can be compiled with -fvisibility=hidden to get the desired behavior

[leorize]

It's found that if the binary was compiled with -pie, we can get the desired behavior.

[waddlesplash]

You don't even need dlopen, this will happen with just regular shared libraries; and the symbols can even be "semi-hidden" as they are when a static library is linked into a regular library.

So this is a higher-priority issue, then.

[jackburton]

Does this happen also on x64 or only or x86/gcc2 ?

[waddlesplash]

Actually it happens on GCC7 only, GCC2 is unaffected. Further testing finds that this affects regular library loads, not just dlopen ones. E.g. a library can have a local function called calloc and then it will override the one from libroot. I'll attach a test binary later.

Adding -Xlinker -Bsymbolic to GCC7 linkspec fixes the issue. Why aren't we doing that already?

[leorize]

It's a separate issue. Using -Bsymbolic does not solve the problem for dlopen(), only for linked libraries.

The linkspec of gcc2 is vastly different from gcc7, and I still haven't know why. I'll push a PR to adjust gcc7 linkspec later.

[korli]

When using ​--export-dynamic Linux behaves the same as Haiku.

This isn't a bug in runtime_loader. Can we close this bug?

[leorize]

On Linux and other *nix as well as Windows, we'd have to ask the linker to get this behavior. But on Haiku this is forced and can't be avoided without ill effects (crashing upon the use of TLS (haven't recheck since @waddlesplash fix), or have all symbols hidden). So I'd say we should not close this bug.