On Monday, 8 April 2013 at 11:21:07 UTC, Jacob Carlborg wrote:
> On 2013-04-08 11:51, Maxim Fomin wrote:
>
>> C main function need to be renamed or D main function should be supplied
>> (then a program would start from C code, not D, but this is not a problem)
>>
>> By the way, druntime links to _Dmain, but does not necessarily forwards
>> to it.
>
> The C main function defined in druntime forward to the D main function. The C main function calls "_d_run_main" and passes in a pointer to the D main function. "_d_run_main" then calls the d main function. Indirectly the C main forwards to D main.

This is exactly why main() does not necessarily forwards to _Dmain().

import std.stdio;

alias extern(C) int function(char[][] args) MainFunc;

extern (C) int _d_run_main(int argc, char **argv, MainFunc mainFunc);

extern(C) int main(int argc, char** argv)
{
    return _d_run_main(argc, argv, &bar);
}

void main()
{
    writeln("D main");
}

extern(C) int bar(char[][] args)
{
    writeln("bar");
    return 0;
}

Guess what would happen.

On 2013-04-08 14:27, Maxim Fomin wrote:

> This is exactly why main() does not necessarily forwards to _Dmain().
>
> import std.stdio;
>
> alias extern(C) int function(char[][] args) MainFunc;
>
> extern (C) int _d_run_main(int argc, char **argv, MainFunc mainFunc);
>
> extern(C) int main(int argc, char** argv)
> {
>      return _d_run_main(argc, argv, &bar);
> }
>
> void main()
> {
>      writeln("D main");
> }
>
> extern(C) int bar(char[][] args)
> {
>      writeln("bar");
>      return 0;
> }
>
> Guess what would happen.

Sure, if you redefine the C main function.

-- 
/Jacob Carlborg

On Monday, 8 April 2013 at 04:16:20 UTC, Walter Bright wrote:
> On 4/7/2013 6:14 PM, Ellery Newcomer wrote:
>> On Sunday, 7 April 2013 at 06:03:38 UTC, Walter Bright wrote:
>>> On 4/6/2013 7:15 PM, Ellery Newcomer wrote:
>>>> dmd  -unittest -fPIC -defaultlib=phobos2so -shared test1.d -oflibtest1.so
>>>> gcc  test1.c `pwd`/libtest1.so -L/usr/lib64/dmd/ -L/usr/lib/dmd/ -o test1.x
>>>> /lib64/libphobos2so.so: undefined reference to `_Dmain'
>>>> collect2: error: ld returned 1 exit status
>>>>
>>>>
>>>> _Dmain? wat?
>>>
>>> _Dmain is the mangled name for main() in your program.
>>
>> Yes, I know, but does it make sense to provide it when I call my shared lib from C?
>
> Currently, I think you'll need a D main().

I think there is no need for D main and it can be fixed simply by defining _Dmain() in druntime. If user defines _Dmain() somewhere in his code, it would be caught by linker, if not the behavior would depend on druntime version. Advantage is that there would be no building errors (may be except when _deh_beg and _deh_end are required), the question is what to do in default version - silently ignore or throw error.

On Monday, 8 April 2013 at 04:35:59 UTC, Maxim Fomin wrote:
>
> DMD inserts some additional info in object file if main() is present and sometimes it is required. One of the solutions is to use dummy D module (with main function defined) which forwards startup arguments to C main function.

My target is python extension modules. I can't touch c main. I can provide a dummy _Dmain and then manually start up and shut down the d runtime; that's the way PyD's been doing it for the last seven years, but I think it breaks when you have more than one shared lib.

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.

On 2013-04-08 20:00, Rainer Schuetze wrote:

> 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.

The D main function as well?

-- 
/Jacob Carlborg

On 08.04.2013 20:54, Jacob Carlborg wrote:
> On 2013-04-08 20:00, Rainer Schuetze wrote:
>
>> 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.
>
> The D main function as well?
>

Inside a DLL you don't run the D main function, and the executable must have it (or WinMain), so it doesn't make sense to define one in the shared druntime DLL.

Depending on whether _Dmain, WinMain or DLLMain is found in the D source code, the corresponding startup code is linked, and only the startup code for _Dmain drags in the the C main function.

On 4/7/2013 11:34 PM, Jacob Carlborg wrote:
> On 2013-04-08 06:16, Walter Bright wrote:
>
>> Currently, I think you'll need a D main().
>
> I don't think that's a good solution. Currently a quick workaround is to declare
> D main as a weak symbol.

That may get rid of the error message, but the issue is getting the dll initialized properly.

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

On 2013-04-09 01:14, Walter Bright wrote:

> That may get rid of the error message, but the issue is getting the dll
> initialized properly.

There's "rt_init", C initializers and Windows DLL main. That's why a described a better solution below.

-- 
/Jacob Carlborg