On 29/09/2023 8:43 PM, FeepingCreature wrote:
> Note that you can still remove TypeInfo that isn't referenced in an executable/library; the only TypeInfo that needs to be exported are those that you actually look at.

The linker can't do that. So you're relying entirely on the compiler for this.

On 29/09/2023 9:04 PM, Alexandru Ermicioi wrote:
> On Thursday, 28 September 2023 at 19:25:15 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> I said this on Discord, but that means all TypeInfo has to be exported, even for executables.
> 
> There might be an issue when your lib uses two other libs, and both of them use lib X but of different versions. This might cause issues with exported structures when they differ from version to version, and etc. Could this also be an issue for exported TypeInfos?

It shouldn't be. As long as everything is the same codegen wise (except pointer values), then two TypeInfo's should compare identically.

But you almost got to the concern, not when there are two different versions of a package, but when they are the same version, but linked into different binaries and not exported.

On Thursday, 28 September 2023 at 15:39:22 UTC, deadalnix wrote:
>> I think it's the same in C++, and sometimes dynamic_cast ends up making string comparisons.
>
> What's the reason for this madness?

For example for GCC => https://github.com/gcc-mirror/gcc/blob/41d6b10e96a1de98e90a7c0378437c3255814b16/libstdc%2B%2B-v3/libsupc%2B%2B/typeinfo#L48

MSVCR => https://github.com/ojdkbuild/tools_toolchain_vs2017bt_1416/blob/master/VC/Tools/MSVC/14.16.27023/crt/src/vcruntime/rtti.cpp#L27

I don't understand any of it, just read "strcmp" in a profiler once in a big C++ app. It turns out it was RTTI which was taking a small percentage of time.

On Friday, 29 September 2023 at 12:15:53 UTC, Guillaume Piolat wrote:
> On Thursday, 28 September 2023 at 15:39:22 UTC, deadalnix wrote:
>>> I think it's the same in C++, and sometimes dynamic_cast ends up making string comparisons.
>>
>> What's the reason for this madness?
>
> For example for GCC => https://github.com/gcc-mirror/gcc/blob/41d6b10e96a1de98e90a7c0378437c3255814b16/libstdc%2B%2B-v3/libsupc%2B%2B/typeinfo#L48
>
> MSVCR => https://github.com/ojdkbuild/tools_toolchain_vs2017bt_1416/blob/master/VC/Tools/MSVC/14.16.27023/crt/src/vcruntime/rtti.cpp#L27
>
> I don't understand any of it, just read "strcmp" in a profiler once in a big C++ app. It turns out it was RTTI which was taking a small percentage of time.

At least the GCC one has some explaination. What stroke me is:

> but even with weak symbols sometimes names are not merged
> when objects are loaded with RTLD_LOCAL

Which seems to indicate the duplication is not a fatality, but they have to handle it because they might be working with stuff that are loaded with RTLD_LOCAL? What does this mean? is this really a constraint that we have?

On Friday, 29 September 2023 at 12:33:13 UTC, deadalnix wrote:
>
> Which seems to indicate the duplication is not a fatality, but they have to handle it because they might be working with stuff that are loaded with RTLD_LOCAL? What does this mean? is this really a constraint that we have?

I'm way underqualified. Using RTLD_NOW (and not sure what it does), it seems to work on all platforms, but I certainly do not expect RTTI to work across binaries. C ABI provides minimum headache. Hipreme also do shared libs, and they went the minimal druntime way. We want less of druntime and Phobos, not more of it.

https://linux.die.net/man/3/dlopen

RTLD_NOW
If this value is specified, or the environment variable LD_BIND_NOW is set to a nonempty string, all undefined symbols in the library are resolved before dlopen() returns. If this cannot be done, an error is returned.

That is fine, this is kinda what you should usually use to prevent errors happening elsewhere (which won't be easily understood).



RTLD_GLOBAL
The symbols defined by this library will be made available for symbol resolution of subsequently loaded libraries.

RTLD_LOCAL
This is the converse of RTLD_GLOBAL, and the default if neither flag is specified. Symbols defined in this library are not made available to resolve references in subsequently loaded libraries.

RTLD_LOCAL basically isolates all exports from one shared library once loaded from being matched to other shared library/executable externs. This is probably what you want when loading plugins.