https://issues.dlang.org/show_bug.cgi?id=9816
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
https://issues.dlang.org/show_bug.cgi?id=9816
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #33 from
https://issues.dlang.org/show_bug.cgi?id=9816
--- Comment #34 from Walter Bright ---
> export int a; // declaration => dllimport // fails because it's actually a
> definition
That's been fixed.
--
https://issues.dlang.org/show_bug.cgi?id=9816
Iain Buclaw changed:
What|Removed |Added
Priority|P2 |P3
--
https://issues.dlang.org/show_bug.cgi?id=9816
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
https://issues.dlang.org/show_bug.cgi?id=9816
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
https://issues.dlang.org/show_bug.cgi?id=9816
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
https://issues.dlang.org/show_bug.cgi?id=9816
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
https://issues.dlang.org/show_bug.cgi?id=9816
Paul Backus changed:
What|Removed |Added
Keywords||bounty
--
https://issues.dlang.org/show_bug.cgi?id=9816
Mike Parker changed:
What|Removed |Added
CC||aldac...@gmail.com
--- Comment #32 from Mike Pa
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #31 from Benjamin Thaut 2013-09-01
02:50:44 PDT ---
I updated the DIP with all discussed changes and implementation details. Please
give feedback in the newsgroup.
http://wiki.dlang.org/DIP45
--
Configure issuemail: http://d.pur
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #30 from Martin Nowak 2013-08-30 08:16:09 PDT ---
(In reply to comment #29)
> The only question remaining is, how big the performance impact is when doing
> cross DLL calls. When the compiler knows that the function is located insid
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #29 from Benjamin Thaut 2013-08-30
07:49:43 PDT ---
> No! This only applies to data that is marked as export. So you do know quite
> well what could be imported.
You are correct, I didn't take into account that we can leverage exp
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #28 from Martin Nowak 2013-08-30 06:07:52 PDT ---
(In reply to comment #24)
> I fully agree here. We might still want to provide a -exportall switch for
> convenience.
A compiler switch makes sense for the case where you have the s
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #27 from Martin Nowak 2013-08-30 05:26:36 PDT ---
And the metadata of exported UDTs (vtable, rtti) and moduleinfos for modules
with exported members. Also note that because Windows doesn't support symbol
interposition it's safe to a
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #26 from Martin Nowak 2013-08-30 05:11:45 PDT ---
(In reply to comment #24)
> > 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
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #25 from Benjamin Thaut 2013-08-30
00:45:28 PDT ---
> That wouldn't work in the case where you create a DLL that both exports
> symbols
> and imports symbols from another DLL.
It would work. Because the command line switch to the
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #24 from Benjamin Thaut 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
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #23 from Martin Nowak 2013-08-29 23:59:07 PDT ---
(In reply to comment #22)
> Do you want to annotate all of phobos and druntime with "export" to build a
> shared version? I think we are already in annotation hell with nothrow, pur
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #22 from Rainer Schuetze 2013-08-29 23:40:47
PDT ---
(In reply to comment #19)
> > - 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 w
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #21 from Martin Nowak 2013-08-29 19:29:11 PDT ---
To summarize the alias proposal.
For every exported function definition we also emit an alias symbol
_imp_funcname.
For every exported data definition we emit a weakly linked read-on
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #20 from Martin Nowak 2013-08-29 15:37:26 PDT ---
(In reply to comment #19)
> > > Well, the question is, whether we can annotate symbols with "export" and
> > > still
> > > create static libraries.
> >
> > At the moment: no. But w
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #19 from Martin Nowak 2013-08-29 15:05:57 PDT ---
(In reply to comment #18)
> - when does export mean dllimport and when dllexport. Newsgroup discussion
> brought up that we could enable dllimport/dllexport per module (including all
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #18 from Benjamin Thaut 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
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #17 from Martin Nowak 2013-08-29 11:54:03 PDT ---
(In reply to comment #16)
> Yes for functions symbols this is true, but data symbols require special
> handling as described before. What are you trying to suggest with this
> statem
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #16 from Benjamin Thaut 2013-08-29
11:44:50 PDT ---
> Maybe my understanding of the Windows mechanism is wrong, but I don't think
> that the exported symbol has to be different. All the runtime binding happens
> in the import libra
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #15 from Martin Nowak 2013-08-29 11:38:04 PDT ---
(In reply to comment #11)
> When a variable is accessed which is linked in through a static library the
> compiler generates a direct access. If it is linked in through a dynamic
> l
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #14 from Rainer Schuetze 2013-08-29 11:12:17
PDT ---
(In reply to comment #10)
> I'm not a big of conflating protection and export. For example you could split
> a library in two DLLs in which case you might need to export/import p
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #13 from Rainer Schuetze 2013-08-29 11:07:40
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 relocat
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #12 from Benjamin Thaut 2013-08-29
09:50:15 PDT ---
I found a excelent blog post on this topic, especially the "auto-linking" part
of it is interresting:
http://blog.omega-prime.co.uk/?p=115
--
Configure issuemail: http://d.pure
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #11 from Benjamin Thaut 2013-08-29
08:28:06 PDT ---
When a variable is accessed which is linked in through a static library the
compiler generates a direct access. If it is linked in through a dynamic
library however the compiler n
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #10 from Martin Nowak 2013-08-29 07:49:41 PDT ---
(In reply to comment #7)
> A few random comments:
>
> - I think in a situation where you want to use the same code for static and
> dynamic linking, "export" is not usable. I'd prop
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #9 from Rainer Schuetze 2013-08-28 23:29:36
PDT ---
Your're right, a function would be simpler. It might be a little less efficient
because of the indirect jump, but avoids the two indirect data accesses through
the import table.
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #8 from Benjamin Thaut 2013-08-27 09:41:35
PDT ---
Wouldn't it be easier to implement a getter function for each TLS variable
which just returns the address of the variable value?
--
Configure issuemail: http://d.puremagic.com/is
http://d.puremagic.com/issues/show_bug.cgi?id=9816
Rainer Schuetze changed:
What|Removed |Added
CC||r.sagita...@gmx.de
--- Comment #7 fr
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #6 from Benjamin Thaut 2013-05-29 06:22:40
PDT ---
Sorry, I wanted to say that I'm not sure if it is possible to make thread local
variables work across dll boundaries so I think we should make it a error first
and might be able to
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #5 from Benjamin Thaut 2013-05-29 06:21:17
PDT ---
> Can't you link against a DLL containing the definition of a thread local
variable?
I can. But I thought that it is better to make something an error it is hard to
implement and
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #4 from Martin Nowak 2013-05-28 09:31:31 PDT ---
> 1) Exporting a global variable leads to a linker error
fixed by bug 10059
> 2) Exporting thread local variables should be an error (at least it is in c++)
Can't you link against a
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #3 from Martin Nowak 2013-04-07 21:32:10 PDT ---
(In reply to comment #0)
> 1) Exporting a global variable leads to a linker error
The problem seems to be that export uses C like rules to distinguish
declarations and definitions. F
http://d.puremagic.com/issues/show_bug.cgi?id=9816
--- Comment #2 from Martin Nowak 2013-04-06 21:12:36 PDT ---
(In reply to comment #1)
> (In reply to comment #0)
> > 2) Exporting thread local variables should be an error (at least it is in
> > c++)
> Yes.
Actually no, at least ELF supports l
http://d.puremagic.com/issues/show_bug.cgi?id=9816
Martin Nowak changed:
What|Removed |Added
CC||c...@dawg.eu
--- Comment #1 from Martin
41 matches
Mail list logo
