[Issue 9816] Export is mostly broken

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=9816



--- Comment #18 from Benjamin Thaut <code at benjamin-thaut.de> 2013-08-29 11:58:13 PDT ---
> Nice blog post. I have implemented something similar to "auto-import" by adding
> some additional relocation data for data accesses. At program start the
> addresses that are relocated to the import table are patched.
> 
> Unfortunately this does not work for 64-bit applications, because relocations
> inside a dmd generated binary are 32-bit pc-relative only. You cannot put the
> address to a variable insde another DLL there as it might be anywhere in the
> 64-bit address space and out of reach for the 32-bit relative address.

A optimization like this would be nice, but walter already stated that he
preferes the classical way (another level of indirection). Maybe we should
first concentrate on the other issues at hand before discussing optimizations. 
The most important beeing:
- when does export mean dllimport and when dllexport. Newsgroup discussion
brought up that we could enable dllimport/dllexport per module (including all
submodules) via a command line switch.
- do we want a export all public symbols feature (discussion on the newsgroup
brought up that c++ is trying to move away from this, maybe we should too)
- Should exporting of entire classes / structs be possible? E.g. marking a
class es export, exports its vtable, typeinfo, all protected / public
functions,
static members, etc.
- Which informations about modules need to be exported? Will they be
automatically exported as soon as the module has a single exported function /
class / variable?

> Well, the question is, whether we can annotate symbols with "export" and still
> create static libraries.

At the moment: no. But we should create a solution where this very case will
work. Proposed solution. 'export' is always a no-op unless you specifiy
otherwise using a command line switch to the compiler.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------