On 04/08/2013 08:00 PM, Rainer Schuetze wrote:
>
>
> On 07.04.2013 17:19, Martin Nowak wrote:
>> On 04/07/2013 10:21 AM, Jacob Carlborg wrote:
>>> On 2013-04-07 04:15, Ellery Newcomer wrote:
>>> I think it needs weak linkage or similar. I don't know if it's possible
>>> to do in D, but in C it can be done like this:
>>>
>>> https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dylib_fixes.c
>>>
>>>
>>>
>>>
>> Yes, druntime should only weakly link against _Dmain.
>>
>
> I think the correct way is to remove the C main function from dmain2.d
> and put it in an extra library to be linked with the executable. At
> least on Windows, you won't be able to link back from the DLL to the
> main executable.

I think the best way is to sythesize a main function in the executable.
Something like this.

extern(C) int main(int argc, char** argv)
{
  rt_init(argc, argv);
  runMain(&_Dmain);
  return rt_term();
}

On 04/08/2013 10:25 AM, Johannes Pfau wrote:
> Then ldconfig is less picky than I thought ;-) The other problem is actually a problem in gcc, not gdc specific: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41816
> 
> Most linux distributions move that file manually to a different location when creating the gcc package.

Aaahh, OK.  If I understand right it's a harmless warning, so I might as well just leave everything where it is ...

On 2013-04-09 17:51, Martin Nowak wrote:

> I think the best way is to sythesize a main function in the executable.
> Something like this.
>
> extern(C) int main(int argc, char** argv)
> {
>    rt_init(argc, argv);
>    runMain(&_Dmain);
>    return rt_term();
> }

By "sythesize", you mean not defined in druntime?

-- 
/Jacob Carlborg

On 04/09/2013 06:49 PM, Jacob Carlborg wrote:
> On 2013-04-09 17:51, Martin Nowak wrote:
>
>> I think the best way is to sythesize a main function in the executable.
>> Something like this.
>>
>> extern(C) int main(int argc, char** argv)
>> {
>>    rt_init(argc, argv);
>>    runMain(&_Dmain);
>>    return rt_term();
>> }
>
> By "sythesize", you mean not defined in druntime?
>
Yes as Rainer pointed out the current mechanism doesn't work well on Windows. Given the simplicity of the needed C function we can simply generate it inside the compiler.

On 04/08/2013 04:18 PM, Walter Bright wrote:
> On 4/5/2013 7:18 PM, Ellery Newcomer wrote:
>> is there a roadmap for druntime/phobos support of shared libraries?
>>
>> just built dmd from master, and I still can't coax out a 64 bit .so
>
> There are the following scenarios:
>
> 1. D executable, C dll => always worked
> 2. D executable, D dll, statically loaded => now in 2.063 HEAD
> 3. D executable, D dll, dynamically loaded (hot swapping) = not yet
> 4. C executable, D dll => not yet

now? :)

On 05/22/2013 08:01 PM, Ellery Newcomer wrote:
> On 04/08/2013 04:18 PM, Walter Bright wrote:
>> On 4/5/2013 7:18 PM, Ellery Newcomer wrote:
>>> is there a roadmap for druntime/phobos support of shared libraries?
>>>
>>> just built dmd from master, and I still can't coax out a 64 bit .so
>>
>> There are the following scenarios:
>>
>> 1. D executable, C dll => always worked
>> 2. D executable, D dll, statically loaded => now in 2.063 HEAD
>> 3. D executable, D dll, dynamically loaded (hot swapping) = not yet
>> 4. C executable, D dll => not yet
> 
> now? :)


Good question, since phobos is now shared...

On 2013-05-23 03:01, Ellery Newcomer wrote:

>> 1. D executable, C dll => always worked
>> 2. D executable, D dll, statically loaded => now in 2.063 HEAD
>> 3. D executable, D dll, dynamically loaded (hot swapping) = not yet
>> 4. C executable, D dll => not yet
>
> now? :)

2 works. 4 could possibly work if it's statically loaded. Although I'm not sure if the runtime will be properly initialized from C.

-- 
/Jacob Carlborg

On 23 May 2013 16:28, Jacob Carlborg <doob@me.com> wrote:

> On 2013-05-23 03:01, Ellery Newcomer wrote:
>
>  1. D executable, C dll => always worked
>>> 2. D executable, D dll, statically loaded => now in 2.063 HEAD
>>> 3. D executable, D dll, dynamically loaded (hot swapping) = not yet
>>> 4. C executable, D dll => not yet
>>>
>>
>> now? :)
>>
>
> 2 works. 4 could possibly work if it's statically loaded. Although I'm not sure if the runtime will be properly initialized from C.
>
> --
> /Jacob Carlborg
>

Is there an ETA for any any of these? case 3 is of critical importance... and also 5. C executable, D dll, dynamically loaded (hot swapping)

On 2013-05-23 12:33, Manu wrote:

> Is there an ETA for any any of these? case 3 is of critical
> importance... and also 5. C executable, D dll, dynamically loaded (hot
> swapping)

I don't know. 5 would probably automatically work if 3 worked, or with minor modifications. As for the ETA, I don't know. See if you can put some pressure Walter or Martin Nowak. I'm talking about Linux and possibly FreeBSD here. Don't know the status on Windows.

-- 
/Jacob Carlborg

On Thursday, 23 May 2013 at 11:45:41 UTC, Jacob Carlborg wrote:
> Don't know the status on Windows.

Hasn't pretty much all of this always worked on Windows?

I've been using DLLs written in D on Windows for years, including in situations where they are loaded by a C application.

It had its issues when it came to sharing TypeInfo and GC instances and whatnot, but it works.