On 02.12.2013 10:36, Joakim wrote:
On Monday, 2 December 2013 at 08:25:39 UTC, Rainer Schuetze wrote:


On 01.12.2013 14:30, Joakim wrote:
//test.d
import core.stdc.stdio;

extern (C) int main() { fputs("doing this for real?", stderr); return
0;}

It doesn't link on Win32, Win64, or Android.  It works on linux and
FreeBSD.  Here's the output on platforms where it doesn't work:

The reason this does not work on Win32/Win64 comes from declaring main
as "extern(C)", which declares "main" for the C runtime. This prevents
adding an implicite include directive to add the phobos library to the
link. This happens only for D's main.
I just tested this: you're right, removing the "extern (C)" linkage for
main fixes the linking problem on Win32/Win64.  That makes sense that
druntime/phobos wasn't added to the link, as the symbols _were_ added by
the above stdio.d for Android.

Where is this "implicit include directive?"  It's confusing because "dmd
-v" shows the exact same linker command being run whether that "extern
(C)" is there before main or not.

The compiler embeds it into the object file if code for "D main" is generated. The respective code is around line 742, glue.c.


So, you should either drop the "extern(C)" or add phobos.lib to the
command line.
Yes, both do fix the problem.

If including the library is not an option, you'll have to repeat the
respective declarations in your source. Just adding core.stdc.stdio to
the command line might also work.
I was reusing the existing Makefiles as much as possible and archiving
the ported core.stdc druntime object files for Android into a
libphobos2.a, as that library name is hardcoded into dmd. Perhaps that
was a mistake, I'll look further into why it doesn't link.

IIRC it is not possible to embed a linker directive into an ELF object file, so it must always be specified on the command line. Maybe the linker is looking for libphobos2.a in the wrong directories?

You can change the name of the runtime library with -defaultlib.

Reply via email to