On 2013-04-21 17:20, Diggory wrote:
OK, thanks I think I've got the hang of the way linking works now - I
was confused about how some things didn't seem to require libs to work,
but now I see it's because those things were compiled into
"druntime.lib" which was compiled into "phobos.lib".
So is this correct, assuming I'm only talking about non-COFF libs:
- D code can link directly to normal C libs
Yes.
- .libs generated by DMD are a superset of normal C .libs, they can
contain normal C functions but DMD also has some way of representing
more complicated D constructs inside the .lib file (but not templates).
Yes and no. DMD produces the same .lib files as any C compiler does. The
differences is that D functions uses mangled names this is to support
overloaded function (two or more functions with the same name but
different argument types), methods and template functions.
- druntime.lib is linked into phobos.lib so only phobos.lib needs to be
linked and the compiler does this automatically (how does this work, is
just hard-coded in?)
Yes, druntime is included in Phobos. The compiler hard codes this (at
least on Posix), add the -v flag when compiling and look at the end of
the output to see the linker command it uses. There's also the dm.ini
(dmd.conf on Posix) that contains a couple of default flags. You'll see
that it adds the search path where Phobos is located.
Is there a compiler independent way to tell the linker to automatically
link in a specific library from within a .d file? (preferable this hint
should still exist in the .di file generated from that .d file, and be
transitive so dependencies automatically get linked in just by
"import"ing the required stuff) If not can I suggest this as a feature?
Yes, pragma(lib, ...); but it won't work for .di files.
http://d.puremagic.com/issues/show_bug.cgi?id=2776
I've switched to using the "head" revision in the repo and building from
source which was surprisingly easy (thanks whoever set that up!) so now
I can just add missing functions to windows.d as I need and rebuild and
no more linker errors!
Am I correct in thinking there is no specific order in the contents of
windows.d? I've rearranged mine so that functions are ordered by module
then header file so I can more easily see if a function already exists,
and if not where to add it. Would these changes be of any use?
In general declarations are order independent. When you start with
nested functions and static-ifs it become order dependent.
--
/Jacob Carlborg
