On Tuesday, 8 March 2016 at 23:13:32 UTC, Anon wrote:
> On Tuesday, 8 March 2016 at 20:26:04 UTC, Yuxuan Shui wrote:
>> [...]
>
> [Note: I phrase my answer in terms of Linux shared libraries (*.so) because D doesn't actually have proper Windows DLL support yet. The same would apply to DLLs, it just feels wrong describing functionality that doesn't exist.]
>
> [...]

Can we left TypeInfo symbol undefined in the shared libraries? i.e. D compiler will strip out TypeInfo definition when creating .so. (Alternatively, we can have TypeInfo always undefined in .o, and generate them in linking stage only when creating executables)

On 03/09/2016 07:05 AM, Yuxuan Shui wrote:

> Can we left TypeInfo symbol undefined in the shared libraries? i.e. D
> compiler will strip out TypeInfo definition when creating .so.
> (Alternatively, we can have TypeInfo always undefined in .o, and
> generate them in linking stage only when creating executables)

That would require a linker that's aware of D but as far as I know, all system languages use the system linker.

Ali

On Wednesday, 9 March 2016 at 22:26:38 UTC, Ali Çehreli wrote:
> On 03/09/2016 07:05 AM, Yuxuan Shui wrote:
>
> > Can we left TypeInfo symbol undefined in the shared
> libraries? i.e. D
> > compiler will strip out TypeInfo definition when creating .so.
> > (Alternatively, we can have TypeInfo always undefined in .o,
> and
> > generate them in linking stage only when creating executables)
>
> That would require a linker that's aware of D but as far as I know, all system languages use the system linker.
>
> Ali

Hmm, how about this:

During compilation, D generate undefined TypeInfo symbols, but it also embed type information in the object file (like what Rust does). And then, when dmd/ldc/gdc/whatever is called for linking executables, it will scan object files and generate another object file containing the TypeInfos, and link them together with the system linker. If the compiler is called for linking shared libraries, it doesn't.

On Thu, Mar 10, 2016 at 01:33:41AM +0000, Yuxuan Shui via Digitalmars-d-learn wrote:
> On Wednesday, 9 March 2016 at 22:26:38 UTC, Ali Çehreli wrote:
> >On 03/09/2016 07:05 AM, Yuxuan Shui wrote:
> >
> >> Can we left TypeInfo symbol undefined in the shared libraries? i.e. D compiler will strip out TypeInfo definition when creating .so. (Alternatively, we can have TypeInfo always undefined in .o, and generate them in linking stage only when creating executables)
> >
> >That would require a linker that's aware of D but as far as I know, all system languages use the system linker.
> >
> >Ali
> 
> Hmm, how about this:
> 
> During compilation, D generate undefined TypeInfo symbols, but it also embed type information in the object file (like what Rust does). And then, when dmd/ldc/gdc/whatever is called for linking executables, it will scan object files and generate another object file containing the TypeInfos, and link them together with the system linker. If the compiler is called for linking shared libraries, it doesn't.

You can't rely on invoking the compiler to link these objects, because if you're using shared libraries, it will be the OS's dynamic linker that will get invoked to resolve the references, and different versions of shared libraries may have a different set of TypeInfo's, and the compiler may not be able to generate the required TypeInfo's.

A better way is to use the OS linker's "weak symbol" feature, where a symbol is allowed to be defined multiple times (with identical content), and the linker (both dynamic and static) will choose the first definition that it finds.


T

-- 
Маленькие детки - маленькие бедки.

On Thursday, 10 March 2016 at 02:14:19 UTC, H. S. Teoh wrote:
> On Thu, Mar 10, 2016 at 01:33:41AM +0000, Yuxuan Shui via Digitalmars-d-learn wrote:
>> [...]
>
> You can't rely on invoking the compiler to link these objects, because if you're using shared libraries, it will be the OS's dynamic linker that will get invoked to resolve the references, and different versions of shared libraries may have a different set of TypeInfo's, and the compiler may not be able to generate the required TypeInfo's.
>
> A better way is to use the OS linker's "weak symbol" feature, where a symbol is allowed to be defined multiple times (with identical content), and the linker (both dynamic and static) will choose the first definition that it finds.

However weak symbol overriding is deprecated on Linux (see ld.so(8)).

If we want to go all out to solve this problem, there are clearly solutions. But for now there doesn't seem to be enough benefit to justify the amount of work needed.

>
>
> T