On Thursday, 29 August 2013 at 08:36:03 UTC, Benjamin Thaut wrote:
> Am 29.08.2013 09:24, schrieb deadalnix:
>> C++ is doing its best to move away from it. We should probably don't
>> follow that convention.
>
> Moving away from what exactly?

Everything being visible by default.

Am 29.08.2013 10:46, schrieb David Nadlinger:
> On Thursday, 29 August 2013 at 08:36:03 UTC, Benjamin Thaut wrote:
>> Am 29.08.2013 09:24, schrieb deadalnix:
>>> C++ is doing its best to move away from it. We should probably don't
>>> follow that convention.
>>
>> Moving away from what exactly?
>
> Everything being visible by default.

So what should be do? So far I like Andrej Mitrovic's solution best. But I think we should omit the placement holder so that instead of "-export std.*" we use "-export std" which basically means the same thing. Otherwise people might geht the idea stuff like this will work "-export *.somesubmodule".

Personally I'm ok with any working solution. I wanted to use shared dlls since I started using D 3 years ago, and nothing has happend in that regard since then.

Kind Regards
Benjamin Thaut

On Thursday, 29 August 2013 at 06:43:39 UTC, 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?

I guess, it adds missing functions which jump to the actual implementation in so. This is done on windows too in import libraries, but export qualifier makes code a little faster because you make one indirect call instead of a direct call + indirect jump (it can be direct, but for this loader should be able to write to the code section to relocate the jump). You also only need an import table for such call.

On Thursday, 29 August 2013 at 09:13:02 UTC, Benjamin Thaut wrote:
> So what should be do? So far I like Andrej Mitrovic's solution best. But I think we should omit the placement holder so that instead of "-export std.*" we use "-export std" which basically means the same thing. Otherwise people might geht the idea stuff like this will work "-export *.somesubmodule".
>
> Personally I'm ok with any working solution. I wanted to use shared dlls since I started using D 3 years ago, and nothing has happend in that regard since then.
>
> Kind Regards
> Benjamin Thaut

Here is my proposal.

Everything is NOT exported on unixes system, just like on windows. It is consistent accross system and provide opportunities for optimizations and faster linkage.

symobol marked as export are understood as ddlexport (or publicly visible on unixes)

import declaration marked as export as understood as importing a module compiled in a shared object. This time, declaration in the imported mopdule marked as export are understood as ddlimport.

Am 29.08.2013 11:42, schrieb deadalnix:
>
> import declaration marked as export as understood as importing a module
> compiled in a shared object. This time, declaration in the imported
> mopdule marked as export are understood as ddlimport.

But what if you import a module that is linked statically? That would mean export would be treated as dllimport and it will fail to link because the _imp_ symbols are missing when linking statically?

On 29.08.2013 11:33, Kagamin wrote:
> On Thursday, 29 August 2013 at 06:43:39 UTC, 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?
>
> I guess, it adds missing functions which jump to the actual
> implementation in so. This is done on windows too in import libraries,
> but export qualifier makes code a little faster because you make one
> indirect call instead of a direct call + indirect jump (it can be
> direct, but for this loader should be able to write to the code section
> to relocate the jump). You also only need an import table for such call.

That's how it works for functions, but what about accesses to data in another DLL?

Suppose phobos being built as a shared library, how do you access typeid(Object) from another DLL, both from code or inside data, e.g. as the base class member of a class info struct?

On 29.08.2013 08:54, 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.
>

I meant the import part. How are accesses or data references to data inside another shared library implemented?

I found a very good articel on the dllimport/dllexport issue on windows explaining both dynamic linking of function symbols and data symbols:

http://blog.omega-prime.co.uk/?p=115

On 08/29/2013 08:30 PM, Rainer Schuetze wrote:
> I meant the import part. How are accesses or data references to data
> inside another shared library implemented?

References from the data segment use absolute relocations.
References from PIC code use the GOT.

On 08/29/2013 12:03 PM, Benjamin Thaut wrote:
> But what if you import a module that is linked statically? That would
> mean export would be treated as dllimport and it will fail to link
> because the _imp_ symbols are missing when linking statically?

Could we create alias symbols?