On 09.01.2013 19:57, Benjamin Thaut wrote:
Am 09.01.2013 16:49, schrieb Andrei Alexandrescu:
On 1/9/13 4:25 AM, Benjamin Thaut wrote:
The compiler is not shared-lib ready. At least not on windows. It does
not support exporting data symbols. E.g.
export uint g_myGlobal;
This is mostly a problem for "hidden" data symbols, like vtables, module
info objects, type info objects and other stuff D relies on.
Are there bugzilla entries for this?
Andrei
Yes its pretty old too. If you read through the discussion in the ticket
and through the code Rainer Schuetze provided you will have a list of
all the issues that need to be fixed for shared dlls to work:
http://d.puremagic.com/issues/show_bug.cgi?id=4071
I doubt it is easily mergeable now, but the major points are listed in
the bug report. Some of the patches are meant as tests whether the
approach is feasable and should be discussed (like the -exportall switch
which might be exporting a bit to much, but could not be implemented by
a def file due to optlink limitations).
In the following patch:
http://d.puremagic.com/issues/attachment.cgi?id=601&action=edit
Rainer Schuetze does manual patching for data symbols. But this is
hardcoded to only work for his phobos shared dll. The function it is
done in is called dll_patchImportRelocations. If I understand DLLs
correctly this should usually be done by the import library that is
created by the compiler for a shared dll. Maybe Rainer can shed some mor
light on this.
The import library can only help with function calls by providing the
call target and creating an indirect jump through the import table to
the actual function in the other DLL.
Data accesses need another indirection through the import table in the
code if they want to access the actual data in another DLL. This
indirection is not generated by the compiler. That's why a pass is made
to patch all relocation into the import table to their respective
targets (which also eliminates the call indirections). It also has the
benefit of being able to use the same object files for static or dynamic
linking.
The hardcoding of the DLL name was meant for testing purposes. What's
needed is a method to figure out whether the target DLL is written in D
and that data relocations are actually wrong. That would support sharing
data between multiple DLLs aswell (It currently only allows sharing
objects created in the D runtime).
Just to make it clear: I distinguish 2 kinds of DLLs written in D:
1. A DLL that contains the statically linked D runtime and interfaces to
other DLLs and the application without sharing ownership (as if all
other DLLs are written in C). This works pretty well on Windows (Visual
D is such a DLL).
2. A DLL that shares ownership of memory, objects, threads, etc with the
executable and other DLLs if they are also written in D. This is
realized by placing the D runtime into its own DLL that is implicitely
loaded with the other binary. (In contrast to some rumors that I
remember that on posix systems the runtime would be linked into the
application image.) This is what the patches in the bugzilla entry
implement.
