On Monday, 28 October 2013 at 17:49:23 UTC, Jacob Carlborg wrote:
> On 2013-10-28 18:45, Steve Teale wrote:
>
>> Is there a description somewhere of how this will work? Is it language,
>> Phobos, linker, or what.
>
> I guess it's compiler and runtime.

That sounds a bit implausible. New language keyword or something to load a library or object file. My best guess is that extern(C) dlopen() will just work correctly, failing that I'd think we need an equivalent Phobos call.

On Monday, 28 October 2013 at 18:01:14 UTC, Steve Teale wrote:
> That sounds a bit implausible. New language keyword or something to load a library or object file. My best guess is that extern(C) dlopen() will just work correctly, failing that I'd think we need an equivalent Phobos call.

1) it is not new, it is the old one that needs fixing : http://dlang.org/attribute.html#ProtectionAttribute

2) it work just fine in Linux (dlopen) because all symbols are exported there by default. Proper symbol visibility definition is still needed for any cross-platform implementation (and for some optimization potential).

Right now on Linux naive dlopen + calling Phobos stdio function from shared lib works on 2.064beta so you can be calm about that part.

On 2013-10-28 19:00, Steve Teale wrote:

> That sounds a bit implausible. New language keyword or something to load
> a library or object file. My best guess is that extern(C) dlopen() will
> just work correctly, failing that I'd think we need an equivalent Phobos
> call.

Sorry, I wasn't very clear. The correct function to use is core.runtime.Runtime.loadLibrary:

https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L178

-- 
/Jacob Carlborg

On 2013-10-28 19:00, Steve Teale wrote:
> On Monday, 28 October 2013 at 17:49:23 UTC, Jacob Carlborg wrote:
>> On 2013-10-28 18:45, Steve Teale wrote:
>>
>>> Is there a description somewhere of how this will work? Is it language,
>>> Phobos, linker, or what.
>>
>> I guess it's compiler and runtime.
>
> That sounds a bit implausible. New language keyword or something to load
> a library or object file. My best guess is that extern(C) dlopen() will
> just work correctly, failing that I'd think we need an equivalent Phobos
> call.

It's not completely done yet but I think core.runtime.Runtime.loadLibrary will be the function used to load libraries. See: https://github.com/D-Programming-Language/druntime/pull/617

-- 
/Jacob Carlborg

On Monday, 28 October 2013 at 20:44:11 UTC, Jacob Carlborg wrote:
>> That sounds a bit implausible. New language keyword or something to load
>> a library or object file. My best guess is that extern(C) dlopen() will
>> just work correctly, failing that I'd think we need an equivalent Phobos
>> call.
>
> It's not completely done yet but I think core.runtime.Runtime.loadLibrary will be the function used to load libraries. See: https://github.com/D-Programming-Language/druntime/pull/617

In the current implementation, just loading a library using the C functions would indeed work, as the D runtime registration/initialization happens in a C .ctor. The actual implementation in druntime is a bit more complex, mainly to handle thread synchronization.

David

On Sunday, 27 October 2013 at 08:08:08 UTC, Steve Teale wrote:
> Any progress?

There is no way to do something best with llvm?
I don't really understand why for static and dynamic libraries we need rely on OS  implementation. llvm intermediate byte code isn't fast enough translatable at runtime?

Actual binaries format on Windows and Linux seems old and limited, I dream of cross platforms compilers that are based on binaries format that contains all necessary information to be able to operate correct inlining,...

It's a real strength that VM based language have to be binary inter-operable. A lot of Java developers don't see C/C++ as portable languages just cause of the necessity to rebuild binaries on each OS even their runs on same architecture.

On Monday, 28 October 2013 at 22:25:12 UTC, Flamaros wrote:
> On Sunday, 27 October 2013 at 08:08:08 UTC, Steve Teale wrote:
>> Any progress?
>
> There is no way to do something best with llvm?
> I don't really understand why for static and dynamic libraries we need rely on OS  implementation. llvm intermediate byte code isn't fast enough translatable at runtime?
>
> Actual binaries format on Windows and Linux seems old and limited, I dream of cross platforms compilers that are based on binaries format that contains all necessary information to be able to operate correct inlining,...

maybe our childrens will see it one day :)

> It's a real strength that VM based language have to be binary inter-operable. A lot of Java developers don't see C/C++ as portable languages just cause of the necessity to rebuild binaries on each OS even their runs on same architecture.

to be honest, many C/C++ developers don't think it is portable, so Java developers are not alone here O_-

On Tuesday, 29 October 2013 at 04:28:24 UTC, evilrat wrote:
> On Monday, 28 October 2013 at 22:25:12 UTC, Flamaros wrote:
>> On Sunday, 27 October 2013 at 08:08:08 UTC, Steve Teale wrote:
>>> Any progress?
>>
>> There is no way to do something best with llvm?
>> I don't really understand why for static and dynamic libraries we need rely on OS  implementation. llvm intermediate byte code isn't fast enough translatable at runtime?
>>
>> Actual binaries format on Windows and Linux seems old and limited, I dream of cross platforms compilers that are based on binaries format that contains all necessary information to be able to operate correct inlining,...
>
> maybe our childrens will see it one day :)

It makes me sad :(

>
>> It's a real strength that VM based language have to be binary inter-operable. A lot of Java developers don't see C/C++ as portable languages just cause of the necessity to rebuild binaries on each OS even their runs on same architecture.
>
> to be honest, many C/C++ developers don't think it is portable, so Java developers are not alone here O_-

On Monday, 28 October 2013 at 20:42:00 UTC, Jacob Carlborg wrote:
> On 2013-10-28 19:00, Steve Teale wrote:
>
>> That sounds a bit implausible. New language keyword or something to load
>> a library or object file. My best guess is that extern(C) dlopen() will
>> just work correctly, failing that I'd think we need an equivalent Phobos
>> call.
>
> Sorry, I wasn't very clear. The correct function to use is core.runtime.Runtime.loadLibrary:
>
> https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L178

I was forgetting the runtime library - that seems like the place ;=)

On Monday, 28 October 2013 at 22:25:12 UTC, Flamaros wrote:
> On Sunday, 27 October 2013 at 08:08:08 UTC, Steve Teale wrote:
>> Any progress?
>
> There is no way to do something best with llvm?
> I don't really understand why for static and dynamic libraries we need rely on OS  implementation. llvm intermediate byte code isn't fast enough translatable at runtime?

LLVM IR is not fully cross-platform, sadly. Sure, the more basic, core feature are platform independent, but once you need more advanced features you will need to adjust the LLVM IR for your architecture, such as x86, x86_64, or ARM.
I'd suggest to give this document a read on the topic: http://llvm.org/docs/LangRef.html