August 27, 2013 DIP45: fixing the dllimport/dllexport issue | ||||
---|---|---|---|---|
| ||||
The current behaviour of export is not sufficient to create a shared runtime on windows. Its alos not working very well in a few other cases. For background information please read the links provided in the DIP. This DIP tries to solve the problem by imitating the proven preprocessor techniques used in C/C++ to create windows dlls. Destroy. Kind Regards Benjamin Thaut |
August 27, 2013 Re: DIP45: fixing the dllimport/dllexport issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Benjamin Thaut | Well, a link would have been great: http://wiki.dlang.org/DIP45 |
August 27, 2013 Re: DIP45: fixing the dllimport/dllexport issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Benjamin Thaut | On Tuesday, 27 August 2013 at 10:16:24 UTC, Benjamin Thaut wrote:
> Well, a link would have been great:
>
> http://wiki.dlang.org/DIP45
I don't think that is the way to go.
We need a way to mark a module as being an "header" import for a shared lib.
With that solution, you'll ends up duplicating all modules with import and export, and putting the export(foobar) all over the place in a module.
|
August 27, 2013 Re: DIP45: fixing the dllimport/dllexport issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | Am 27.08.2013 13:28, schrieb deadalnix:
> On Tuesday, 27 August 2013 at 10:16:24 UTC, Benjamin Thaut wrote:
>> Well, a link would have been great:
>>
>> http://wiki.dlang.org/DIP45
>
> I don't think that is the way to go.
>
> We need a way to mark a module as being an "header" import for a shared
> lib.
>
> With that solution, you'll ends up duplicating all modules with import
> and export, and putting the export(foobar) all over the place in a module.
Well ideally it should be enough to put one
export(foobar): at the top of the file.
Also I don't see why there is any duplication of modules involved? What exactly do you mean?
And how should your header import for a shared lib work, if you link against exactly that lib statically?
Kind Regards
Benjamin Thaut
|
August 27, 2013 Re: DIP45: fixing the dllimport/dllexport issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Benjamin Thaut | On 8/27/13, Benjamin Thaut <code@benjamin-thaut.de> wrote:
> Well, a link would have been great:
>
> http://wiki.dlang.org/DIP45
Using export(identifier) is not going to be reliable, since chances of
clashes are high.
E.g. if libFoo uses export(Foo) and libBar also uses export(Foo), you
won't be able to distinguish between the two.
Instead I think 'identifier' should be a module name.
However, I have a better idea. Why not only introduce compiler switches that are based on module names rather than having to annotate what export does in code? For example:
dmd -m64 -export libB.* -import libA.* -of"libB.dll" dllmain.d libB.d -L/DLL -L/IMPLIB:"libB.lib" -LlibA.lib
"-export libB.*" means all modules and subpackages of the libB package should be exported, whereas "-import libA.*" means the opposite for libA.
This way you don't have to edit any existing code.
|
August 27, 2013 Re: DIP45: fixing the dllimport/dllexport issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | Am 27.08.2013 15:33, schrieb Andrej Mitrovic:
> On 8/27/13, Benjamin Thaut <code@benjamin-thaut.de> wrote:
>> Well, a link would have been great:
>>
>> http://wiki.dlang.org/DIP45
>
> Using export(identifier) is not going to be reliable, since chances of
> clashes are high.
> E.g. if libFoo uses export(Foo) and libBar also uses export(Foo), you
> won't be able to distinguish between the two.
>
> Instead I think 'identifier' should be a module name.
>
> However, I have a better idea. Why not only introduce compiler
> switches that are based on module names rather than having to annotate
> what export does in code? For example:
>
> dmd -m64 -export libB.* -import libA.* -of"libB.dll" dllmain.d libB.d
> -L/DLL -L/IMPLIB:"libB.lib" -LlibA.lib
>
> "-export libB.*" means all modules and subpackages of the libB package
> should be exported, whereas "-import libA.*" means the opposite for
> libA.
>
> This way you don't have to edit any existing code.
>
I thought about something along those lines aswell. But wouldn't that create a very long command line if you do it for druntime?
|
August 29, 2013 Re: DIP45: fixing the dllimport/dllexport issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Benjamin Thaut |
On 27.08.2013 15:40, Benjamin Thaut wrote:
> Am 27.08.2013 15:33, schrieb Andrej Mitrovic:
>> On 8/27/13, Benjamin Thaut <code@benjamin-thaut.de> wrote:
>>> Well, a link would have been great:
>>>
>>> http://wiki.dlang.org/DIP45
>>
>> Using export(identifier) is not going to be reliable, since chances of
>> clashes are high.
>> E.g. if libFoo uses export(Foo) and libBar also uses export(Foo), you
>> won't be able to distinguish between the two.
>>
>> Instead I think 'identifier' should be a module name.
>>
>> However, I have a better idea. Why not only introduce compiler
>> switches that are based on module names rather than having to annotate
>> what export does in code? For example:
>>
>> dmd -m64 -export libB.* -import libA.* -of"libB.dll" dllmain.d libB.d
>> -L/DLL -L/IMPLIB:"libB.lib" -LlibA.lib
>>
>> "-export libB.*" means all modules and subpackages of the libB package
>> should be exported, whereas "-import libA.*" means the opposite for
>> libA.
>>
>> This way you don't have to edit any existing code.
>>
>
> I thought about something along those lines aswell. But wouldn't that
> create a very long command line if you do it for druntime?
I think export (at module granularity) can be handled by building the modules with symbols to export using a command line switch "-exportall", and all other modules without.
I'd prefer if the compilation against the imported library would be agnostic whether it is later linked against a static or dynamic library.
How is this done on linux right now? It does not need "export"/"import" to build against a shared phobos library. Is "import" assumed for any data access and later removed by some magic in the linker?
|
August 29, 2013 Re: DIP45: fixing the dllimport/dllexport issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rainer Schuetze | On 2013-08-29 08:43, Rainer Schuetze wrote: > How is this done on linux right now? It does not need "export"/"import" > to build against a shared phobos library. Is "import" assumed for any > data access and later removed by some magic in the linker? "export" is noop on Posix. Every symbol is accessible. -- /Jacob Carlborg |
August 29, 2013 Re: DIP45: fixing the dllimport/dllexport issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Thursday, 29 August 2013 at 06:54:46 UTC, Jacob Carlborg wrote:
> On 2013-08-29 08:43, Rainer Schuetze wrote:
>
>> How is this done on linux right now? It does not need "export"/"import"
>> to build against a shared phobos library. Is "import" assumed for any
>> data access and later removed by some magic in the linker?
>
> "export" is noop on Posix. Every symbol is accessible.
C++ is doing its best to move away from it. We should probably don't follow that convention.
|
August 29, 2013 Re: DIP45: fixing the dllimport/dllexport issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | Am 29.08.2013 09:24, schrieb deadalnix: > On Thursday, 29 August 2013 at 06:54:46 UTC, Jacob Carlborg wrote: >> On 2013-08-29 08:43, Rainer Schuetze wrote: >> >>> How is this done on linux right now? It does not need "export"/"import" >>> to build against a shared phobos library. Is "import" assumed for any >>> data access and later removed by some magic in the linker? >> >> "export" is noop on Posix. Every symbol is accessible. > > C++ is doing its best to move away from it. We should probably don't > follow that convention. Moving away from what exactly? -- Kind Regards Benjamin Thaut |
Copyright © 1999-2021 by the D Language Foundation