[Issue 9816] Export is mostly broken

d-bugmail at puremagic.com d-bugmail at puremagic.com
Fri Aug 30 00:32:52 PDT 2013


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



--- Comment #24 from Benjamin Thaut <code at benjamin-thaut.de> 2013-08-30 00:32:50 PDT ---
> I don't think the last point is too critical because exporting data is rarely
> done and rather a bad practice.
> Also this only applies to the API boundary which shouldn't be a performance
> hotspot.

The digital mars linker is not capable of doing so. Also as stated on the
newsgroup we will most likely not be able to use LTO of the mircosoft linker.
Also this will not only affect to API bounadries, it will affect all accesses
to global data: __gshared variables, shared variables, and all compiler
internal global data symbols like module info, type info, vtables, etc. This is
because without knowing what symbols are imported from a DLL we have to add the
indirection to all of them. If we decide to use the alias solution we would
have to accept the additional level of indirection for all global data accesses
and keep in mind that this is most likely going to stay that way for a long
time.

> Yes, that's what I intend. Doing this manually is important, because exporting
> a symbol means commiting to ABI stability, which should be a longterm goal.
> Because exported symbols are the known entry points of a library this reopens
> the question whether we could use much more inference for non-exported symbols.

I fully agree here. We might still want to provide a -exportall switch for
convenience.

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


More information about the Digitalmars-d-bugs mailing list