• dmd (Windows)
• dmd (Linux)
• dmd (OSX)
• dmd (FreeBSD)
• rdmd
• install.sh
• htod

DMD Compiler for Windows

• Requirements and Downloads
• Installation
• Example
• Compiler Arguments and Switches
• Files
• Linking
• Environment Variables
• sc.ini Initialization File
• Common Installation Problems
• Differences between Windows and Linux versions
• D Interface Files
• Building Libraries
• Compiling dmd
• Compiling Phobos

Requirements and Downloads

1. DMD Compiler
2. Windows operating system, Windows 7 or later, 32 or 64 bit

Installation

Open a console window (for Windows this is done by clicking on [Start][Command Prompt]). All the tools are command line tools, which means they are run from a console window. Switch to the root directory. Unzip the files in the root directory. dmd.zip will create a \dmd2 directory with all the files in it.

A typical session might look like:

C:\Documents and Settings\Your Name>cd \
C:\>unzip dmd.zip

Compiler Arguments and Switches

dmd files... -switches...

files...

File Extensions

Extension	File Type
.c	C source files
.d	D source files
.dd	Ddoc source files
.di	D interface files
.h	C header files
.i	preprocessed C source files
.obj	Object files to link in
.lib	Object code libraries to search
.def	module definition file
.res	resource file

@cmdfile

If cmdfile is an environment variable, read the compiler arguments and switches from the value of that variable. Otherwise, read compiler arguments and switches from the text file cmdfile. The file may contain single-line comments starting with the hash symbol (#).

-allinst

Generate code for all template instantiations

-betterC

Adjusts the compiler to implement D as a better C:

• Predefines D_BetterC version.
• Assert Expressions, when they fail, call the C runtime library assert failure function rather than a function in the D runtime.
• Array overflows call the C runtime library assert failure function rather than a function in the D runtime.
• Final switch errors call the C runtime library assert failure function rather than a function in the D runtime.
• Does not automatically link with phobos runtime library.
• Module constructors and destructors are not generated meaning that static and shared static constructors and destructors will not get called.
• ModuleInfo is not generated.
• TypeInfo instances will not be generated for structs.

-boundscheck=[on|safeonly|off]

Controls if bounds checking is enabled.

• on: Bounds checks are enabled for all code. This is the default.
• safeonly: Bounds checks are enabled only in @safe code. This is the default for -release builds.
• off: Bounds checks are disabled completely (even in @safe code). This option should be used with caution and as a last resort to improve performance. Confirm turning off @safe bounds checks is worthwhile by benchmarking.

-c

Compile only, do not link

-check=action[=[on|off|safeonly]]

Enable or disable specific checks. Overrides default, -boundscheck, -release and -unittest options to enable or disable specific checks. action can be:

• assert: assertion checking
• bounds: array bounds
• in: in contracts
• invariant: class/struct invariants
• nullderef: null dereference
• out: out contracts
• switch: final switch failure checking

Each action can be set to:

• on: specified check is enabled.
• off: specified check is disabled.
• safeonly: check is enabled only in @safe functions.

If no setting for action is given, it will default to on, except nullderef defaults to off.

-check=[on|off]

Enable or disable all checks above.

-check=[h|help|?]

List information on all available checks

-checkaction=[D|C|halt|context]

Sets behavior when an assert or an array bounds check fails, or a final switch errors.

• D: Default behavior, which throws an unrecoverable AssertError.
• C: Calls the C runtime library assert failure function.
• halt: Executes a halt instruction, terminating the program.
• context: Prints the error context as part of the unrecoverable AssertError.

-checkaction=[h|help|?]

List information on all available check actions

-checkactionfinally=[on|off]

Default behavior is on. Turning this off means destructors may not run.

-color

Turn colored console output on

-color=[on|off|auto]

Show colored console output. The default depends on terminal capabilities.

• auto: use colored output if a tty is detected (default)
• on: always use colored output.
• off: never use colored output.

-conf=filename

Use config file at filename

-cov

Perform code coverage analysis and generate .lst file with report.

dmd -cov -unittest myprog.d

-cov=ctfe

Include code executed during CTFE in coverage report

-cov=nnn

Perform code coverage analysis, requiring at least nnn% code coverage. Options can be combined, e.g. -cov=100 -cov=ctfe.

-cpp=filename

Sets the C preprocessor to filename. Normally the C preprocessor used by the associated C compiler is used to preprocess ImportC files.

-D

Generate documentation from source.

Note: mind the security considerations.

-Dddirectory

Write documentation file to directory . -op can be used if the original package hierarchy should be retained

-Dffilename

Write documentation file to filename

-d

Silently allow deprecated features and use of symbols with deprecated attributes.

-de

Issue an error when deprecated features or symbols are used (halt compilation)

-dw

Issue a message when deprecated features or symbols are used (default)

-debug

Compile in debug code

-debug=ident

Compile in debug code with debug identifier ident

-debuglib=libname

Link in libname as the default library when compiling for symbolic debugging instead of phobos.lib. If libname is not supplied, then no default library is linked in.

-defaultlib=libname

Link in libname as the default library when not compiling for symbolic debugging instead of phobos.lib. If libname is not supplied, then no default library is linked in.

-deps

Print module dependencies (imports/file/version/debug/lib)

-deps=filename

Write module dependencies as text to filename (only imports).

-dllimport=[none|defaultLibsOnly|externalOnly|all]

Which symbols to dllimport implicitly if not defined in a module that is being compiled

• none: None
• defaultLibsOnly: Only druntime/Phobos symbols and any from a module that is marked as external to binary
• externalOnly: Only symbols found from a module that is marked as external to binary
• all: All

-edition[=NNNN[filename]]

Set edition to default which is 2023, to a particular year NNNN, apply edition only to filename

-extern-std=standard

Set C++ name mangling compatibility with standard. Standards supported are:

• c++98: Use C++98 name mangling, Sets __traits(getTargetInfo, "cppStd") to 199711
• c++11 (default): Use C++11 name mangling, Sets __traits(getTargetInfo, "cppStd") to 201103
• c++14: Use C++14 name mangling, Sets __traits(getTargetInfo, "cppStd") to 201402
• c++17: Use C++17 name mangling, Sets __traits(getTargetInfo, "cppStd") to 201703
• c++20: Use C++20 name mangling, Sets __traits(getTargetInfo, "cppStd") to 202002
• c++23: Use C++23 name mangling, Sets __traits(getTargetInfo, "cppStd") to 202302

-extern-std=[h|help|?]

List all supported standards

-fIBT

Generate Indirect Branch Tracking code

-fPIC

Generate position independent code

-fPIE

Generate position independent executables

-ftime-trace

Measure the time to analyze, call from CTFE, and generate code for a function. Events with a time longer than 500 microseconds (adjustable with -ftime-trace-granularity) will be recorded. The profiling result is output in the Chrome Trace Event Format, described here. This can be turned into a more readable text file with the included tool timetrace2txt, or inspected with an interactive viewer such as Perfetto.

-ftime-trace-granularity=μsecs

Minimum time granularity (in microseconds) traced by time profiler. The default is 500. Measured events shorter than the specified time will be discarded from the output. Set it too high, and interesting events may not show up in the output. Set too low, and the profiler overhead will be larger, and the output will be cluttered with tiny events.

-ftime-trace-file=filename

Specify output file for -ftime-trace. By default, the output name is the same as the first object file name, but with the .time-trace extension appended. A different filename can be chosen with this option, including a path relative to the current directory or an absolute path.

-g

Add CodeView symbolic debug info. See Debugging on Windows.

-gdwarf=version

Add DWARF symbolic debug info. The value of version may be 3, 4 or 5, defaulting to 3.

-gf

Emit debug info for all referenced types. Symbolic debug info is emitted for all types referenced by the compiled code, even if the definition is in an imported file not currently being compiled.

-gs

Always emit stack frame

-gx

Adds stack stomp code, which overwrites the stack frame memory upon function exit.

-H

Generate D interface file

-Hd=directory

Write D interface file to directory. -op can be used if the original package hierarchy should be retained.

-Hf=filename

Write 'header' file to filename

-HC=[silent|verbose]

Write C++ 'header' equivalent to stdout configured with:

silent

only list extern(C[++]) declarations (default)

verbose

also add comments for ignored declarations (e.g. extern(D))

-HC=[?|h|help]

List available options for C++ 'header' file generation

-HCd=directory

Write C++ 'header' file to directory, ignored if -HCf=filename is not present

-HCf=filename

Write C++ 'header' file to filename instead of stdout

--help

Print help and exit

-I=directory

Adds directory to the list of paths to be searched for imports. Multiple -I's can be used, and the paths are searched in the same order.

The process of finding a module during the resolution of an import declaration involves several steps.

• Search paths: dmd searches for the module in all directories specified with the -I option in the following sequence:
  1. From the command line.
  2. From the DFLAGS setting in the initialization file.
  3. From the environment variable if no setting was found in the initialization file.
  4. If the module cannot be found in any of the import paths, then the current working directory is searched instead.
• Module name mapping: The chain of identifiers in a fully qualified module name is translated into a corresponding file name. This involves:
  • Replacing dots (.) in the module name with directory separators (\).
  • Appending the appropriate file extension.
  • Look for a package module if the file name is a directory.
• File extensions: Modules are matched to files with specific file extensions. The order in which each extension is searched is as follows:
  1. .di
  2. .d
  3. package.di
  4. package.d
  5. .i
  6. .h
  7. .c
• Module filename aliases: The relationship between module names and their corresponding source files can be defined explicitly with the -mv command line option. For example, -mv=foo=source or -mv=foo.bar=source/file.d.
  1. When an imported module matches a module filename alias, then the filename spec is used as the source file location. File name extensions are checked in order if no extension was given in the filename spec.
  2. When the package name of an imported module matches a module filename alias, then the filename spec is used as the search path. No other search paths are used to locate the module.

-extI=directory

Look for imports that are out of the currently compiling binary, used to set the module as DllImport

-i[=pattern]

Enables "include imports" mode, where the compiler will include imported modules in the compilation, as if they were given on the command line. By default, when this option is enabled, all imported modules are included except those in druntime/phobos. This behavior can be overridden by providing patterns via -i=pattern. A pattern of the form -i=package is an "inclusive pattern", whereas a pattern of the form -i=-package is an "exclusive pattern". Inclusive patterns will include all module's whose names match the pattern, whereas exclusive patterns will exclude them. For example. all modules in the package foo.bar can be included using -i=foo.bar or excluded using -i=-foo.bar. Note that each component of the fully qualified name must match the pattern completely, so the pattern foo.bar would not match a module named foo.barx.

The default behavior of excluding druntime/phobos is accomplished by internally adding a set of standard exclusions, namely, -i=-std -i=-core -i=-etc -i=-object. Note that these can be overridden with -i=std -i=core -i=etc -i=object.

When a module matches multiple patterns, matches are prioritized by their component length, where a match with more components takes priority (i.e. pattern foo.bar.baz has priority over foo.bar).

By default modules that don't match any pattern will be included. However, if at least one inclusive pattern is given, then modules not matching any pattern will be excluded. This behavior can be overridden by usig -i=. to include by default or -i=-. to exclude by default.

Note that multiple -i=... options are allowed, each one adds a pattern.

-identifiers=[UAX31|c99|c11|all]

Set the identifier table to use for the non-ASCII values.

• UAX31: UAX31
• c99: C99
• c11: C11
• all: All, the least restrictive set, which comes with all others (default)

-identifiers-importc=[UAX31|c99|c11|all]

Set the identifier table to use for the non-ASCII values.

• UAX31: UAX31
• c99: C99
• c11: C11 (default)
• all: All, the least restrictive set, which comes with all others

-ignore

Deprecated flag, unsupported pragmas are always ignored now

-inline

Inline functions at the discretion of the compiler. This can improve performance, at the expense of making it more difficult to use a debugger on it.

-J=directory

Where to look for files for ImportExpressions. This switch is required in order to use ImportExpressions. directory is a ; separated list of paths. Multiple -J's can be used, and the paths are searched in the same order.

-L=linkerflag

Pass linkerflag to the linker optlink.exe , for example, ld

-lib

Generate library file as output instead of object file(s). All compiled source files, as well as object files and library files specified on the command line, are inserted into the output library. Compiled source modules may be partitioned into several object modules to improve granularity. The name of the library is taken from the name of the first source module to be compiled. This name can be overridden with the -of switch.

-lowmem

Enable the garbage collector for the compiler, reducing the compiler memory requirements but increasing compile times.

-m32

-m32mscoff

Generate 32 bit code and write MS-COFF object files (deprecated use -m32)

-m64

The generated object code is in MS-COFF and is meant to be used with the Microsoft Visual Studio 10 or later compiler.

-marm64

Compile an Arm 64 bit executable. Only supported for OSX.

-main

Add a default main() function when compiling. This is useful when unittesting a library, as it enables running the unittests in a library without having to manually define an entry-point function.

-makedeps[=filename]

Print dependencies in Makefile compatible format. If filename is omitted, it prints to stdout. The emitted targets are the compiled artifacts (executable, object files, libraries). The emitted dependencies are imported modules and imported string files (via -J switch). Special characters in a dependency or target filename are escaped in the GNU Make manner.

-man

Open default browser on this page

-map

Generate a .map file

-mcpu=[baseline|avx|native]

Set the target architecture for code generation, where:

baseline

the minimum architecture for the target platform (default)

avx

generate AVX instructions instead of SSE instructions for vector and floating point operations. Not available for 32 bit memory models other than OSX32.

native

use the architecture the compiler is running on

-mcpu=[h|help|?]

List all architecture options

-mixin=filename

Expand and save mixins to file specified by filename

-mscrtlib=libname

If building MS-COFF object files when targeting Windows, embed a reference to the given C runtime library libname into the object file containing main, DllMain or WinMain for automatic linking. The default is libcmt (release version with static linkage), which uses the Universal CRT (UCRT) shipped with Visual Studio 2015 (or later) and the Windows 10 SDK. The other usual alternatives are libcmtd, msvcrt and msvcrtd. If no Universal CRT capable Visual C installation is detected, the UCRT-based libraries bundled with DMD (the mingw ucrtbase.lib and vcruntime140.lib) are linked instead using the LLD linker provided by the LLVM project. If libname is empty, no C runtime library is automatically linked in.

-mv=package.module=filespec

Use path/filename as the source file for package.module. This is used when the source file path and names are not the same as the package and module hierarchy. The rightmost components of the path/filename and package.module can be omitted if they are the same.

-noboundscheck

Turns off all array bounds checking, even for safe functions. Deprecated (use -boundscheck=off instead).

-nothrow

Turns off generation of exception stack unwinding code, enables more efficient code for RAII objects. Note: this doesn't change function mangling, so it is possible to link -nothrow code with code that throws Exceptions, which can result in undefined behavior without any protection from the type system. Prefer the nothrow function attribute for partial disabling of Exceptions instead, and only use this flag to globally disable Exceptions.

-nothrow-optimizations

Controls whether finally blocks are emitted when the try body is nothrow. By default, finally blocks always run, ensuring cleanup on Error as well. With this option, finally blocks are skipped in nothrow try bodies, which may prevent destructors and scope(exit) blocks (which implicitly generate a try-finally block) from running when an Error is thrown.

-O

Optimize generated code. For fastest executables, compile with the -O -release -inline -boundscheck=off switches together.

-o-

Suppress generation of object file. Useful in conjuction with -D or -H flags.

-od=directory

Write object files relative to directory instead of to the current directory. -op can be used if the original package hierarchy should be retained

-of=filename

Set output file name to filename in the output directory. The output file can be an object file, executable file, or library file depending on the other switches.

-op

Preserve source path for output files. Normally the path for .d source files is stripped off when generating an object, interface, or Ddoc file name.

-oq

Write object files with fully qualified file names. When compiling pkg/app.d, the resulting object file name will be pkg_app.o instead of app.o. This helps to prevent name conflicts when compiling multiple packages in the same directory with the -od flag.

-os=os

Set the target operating system as other than the host.

• host: Target the host operating system (default).
• dragonflybsd: DragonFlyBSD
• freebsd: FreeBSD
• linux: Linux
• openbsd: OpenBSD
• osx: OSX
• solaris: Solaris
• hurd: Hurd
• windows: Windows

-P=preprocessorflag

Pass preprocessorflag to cl.exe . See also -cpp

-preview=name

Preview an upcoming language change identified by name

-preview=[h|help|?]

List all upcoming language changes

-profile

Instrument the generated code so that runtime performance data is collected when the generated program is run. Upon completion of the generated program, the files trace.log and trace.def are generated. trace.log has two sections:

1. Fan in and fan out for each profiled function. The name of the function is left-justified, the functions immediately preceding it are the other functions that call it (fan in) and how many times it is called. The functions immediately following are the functions that are called (fan out) and how many times it calls that function. The function itself has 3 numbers appended: the aggregate of the fan in counts, the tree time used by the function which is the function time plus the tree times of all the functions it calls, and the time used excluding the time used by fan out.
2. Timing data for each function, sorted from most used to least.

The trace.def file contains linker commands to associate functions which are strongly coupled so they appear adjacent in the resulting executable file. For more information see profile.

-profile=gc

Instrument calls to GC memory allocation and write a report to the file profilegc.log upon program termination. Note: Only instrumented calls will be logged. These include:

• Language constructs that allocate memory
• Phobos functions that allocate GC memory
• GC allocations via core.memory.GC

Allocations made by other means will not be logged, including direct calls to the GC's C API.

-release

Compile release version, which means not emitting run-time checks for contracts and asserts. Array bounds checking is not done for system and trusted functions, and assertion failures are undefined behaviour.

-revert=name

Revert language change identified by name

-revert=[h|help|?]

List all revertable language changes

-run srcfile args

Compile, link, and run the program srcfile with the rest of the command line, args..., as the arguments to the program. No .obj or executable file is left behind.

-shared

Generate DLL library

-target=arch-[vendor-]os[-cenv[-cppenv]]

Set CPU architecture, OS, C runtime and C++ runtime:

• arch is the architecture: either x86, x64, x86_64 or x32
• vendor is always ignored, but supported for easier interoperability
• os is the operating system, this may have a trailing version number:
• freestanding for no operating system
• darwin or osx for MacOS
• dragonfly or dragonflybsd for DragonflyBSD
• freebsd, openbsd, linux, solaris, hurd or windows for their respective operating systems
• cenv is the C runtime environment and is optional:
• musl for musl-libc
• msvc for the MSVC runtime
• bionic for the Android libc
• gnu or glibc for the GCC C runtime
• newlib or uclibc for their respective C runtimes
• cppenv is the C++ runtime environment:
• clang for the LLVM C++ runtime
• gcc for GCC's C++ runtime
• msvc for microsoft's MSVC C++ runtime
• sun for Sun's C++ runtime

-transition=name

Show additional info about language change identified by name

-transition=[h|help|?]

List all language changes

-unittest

Compile in unittest code, turns on asserts, and sets the unittest version identifier

-unittest-roots

Compile in unittest code, turns on asserts, and sets the unittest version identifier only for root modules whose sources files are explicitly passed as arguments to compiler

-v

Enable verbose output for each compiler pass

-vasm[=string]

string restricts the disassembly to functions for which string is a substring of its name

-vcolumns

Print character (column) numbers in diagnostics

-verror-style=[digitalmars|gnu|sarif]

Set the style for file/line number annotations on compiler messages, where:

digitalmars

'file(line[,column]): message'. This is the default.

gnu

'file:line[:column]: message', conforming to the GNU standard used by gcc and clang.

sarif

'Generates JSON output conforming to the SARIF (Static Analysis Results Interchange Format) standard, useful for integration with tools like GitHub and other SARIF readers.'

-verror-supplements=num

Limit the number of supplemental messages for each error (0 means unlimited)

-verrors=num

Limit the number of error/deprecation messages (0 means unlimited)

-verrors=[context|simple]

Set the verbosity of error messages:

context

Show error messages with the context of the erroring source line (including caret).

simple

Show error messages without the context of the erroring source line.

-verrors=spec

Show errors from speculative compiles such as __traits(compiles, ...)

--version

Print compiler version and exit

-version=ident

Compile in version identifier ident

-vgc

List all GC allocations including hidden ones

-visibility=[default|hidden|public]

• default: hidden for Windows targets without -shared, otherwise public
• hidden: Only export symbols marked with export
• public: Export all symbols

-vtls

List all variables going into thread local storage

-vtemplates[=list-instances]

List statistics on template instantiations. An optional argument determines extra diagnostics:

list-instances

Also shows all instantiation contexts for each template.

-w

Enable warnings

-wi

Enable informational warnings (i.e. compilation still proceeds normally)

-X

Generate JSON file

-Xf=filename

Write JSON file to filename

-Xcc=driverflag

Pass driverflag to the linker driver ($CC or cc)

Empty command line arguments, i.e. "", are ignored.

Files

\dmd2\src\phobos\

D runtime library source

\dmd2\src\dmd\

D compiler front end source under dual (GPL and Artistic) license

\dmd2\html\d\

Documentation

\dmd2\windows\bin\ddemangle.exe

D symbol demangler

\dmd2\windows\bin\dmd.exe

D compiler executable

\dmd2\windows\bin\dub.exe

D's package manager

\dmd2\windows\bin\dustmite.exe

D source code minimizer

\dmd2\windows\bin\rdmd.exe

D build tool for script-like D code execution

\dmd2\windows\bin\sc.ini

Global compiler settings

\dmd2\windows\lib$(LIB)

D runtime library

Linking

Linking is done directly by the dmd compiler after a successful compile. To prevent dmd from running the linker, use the -c switch.

32 bit programs must be linked with the D runtime library phobos.lib, followed by the Digital Mars C runtime library snn.lib. This is done automatically as long as the directories for the libraries are on the LIB environment variable path. A typical way to set LIB would be:

set LIB=\dmd2\lib;\dm\lib

If the dmd command is used to both compile and link to an executable, it will make certain optimizations that are valid only for Windows executable files. Do not use the resulting .obj files in a DLL. To compile modules into .obj files that can be used in an exe or DLL, compile with -c and -shared.

Linking 32 bit programs is done using Digital Mars optlink.exe.

Linking 64 bit programs is done using the Microsoft linker by default. If the Microsoft linker is not found, the included LLVM linker LLD will be used.

Environment Variables

The D compiler dmd uses the following environment variables:

DFLAGS

The value of DFLAGS is treated as if it were appended to the command line to dmd.exe.

LIB

The linker uses LIB to search for library files. For D, it will normally be set to:

set LIB=\dmd2\lib;\dm\lib

LINKCMD

dmd normally runs the linker by looking for optlink.exe along the PATH. To use a specific linker for 32 bit programs instead, set the LINKCMD environment variable to it. For example:

set LINKCMD=\dmd\windows\bin\link

LINKCMD64

dmd normally runs the linker by looking for optlink.exe along the PATH. To use a specific linker for 64 bit programs instead, set the LINKCMD64 environment variable to it. For example:

set LINKCMD64=C:\Program Files (x86)\Microsoft Visual Studio 15.0\VC\bin\amd64\link.exe

PATH

If the linker is not found in the same directory as dmd.exe is in, the PATH is searched for it. Note: other linkers named link.exe will likely not work. Make sure the Digital Mars optlink.exe is found first in the PATH before other link.exes, or use LINKCMD to specifically identify which linker to use.

sc.ini Initialization File

dmd will look for the initialization file sc.ini in the following sequence of directories:

1. current working directory
2. directory specified by the HOME environment variable
3. directory dmd.exe resides in

If found, environment variable settings in the file will override any existing settings. This is handy to make dmd independent of programs with conflicting use of environment variables.

Initialization File Format

Comments are lines that begin with ; and are ignored.

Environment variables follow the [Environment] section heading, in NAME=value pairs. The NAMEs are treated as upper case. Comments are lines that start with ;. For example:

; sc.ini file for dmd
; Names enclosed by %% are searched for in the existing environment
; and inserted. The special name %@P% is replaced with the path
; to this file.
[Environment]
LIB="%@P%..\lib";\dm\lib

DFLAGS="-I%@P%..\src\phobos" "-I%@P%..\src\druntime\import"
LINKCMD="%@P%....\dm\bin"
DDOCFILE=mysettings.ddoc

Location Independence of sc.ini

The %@P% is replaced with the path to sc.ini. Thus, if the fully qualified file name sc.ini is c:\dmd2\bin\sc.ini, then %@P% will be replaced with c:\dmd2\bin, and the above sc.ini will be interpreted as:

[Environment]
LIB="c:\dmd2\bin..\lib";\dm\lib

DFLAGS="-Ic:\dmd2\bin..\src\phobos" "-Ic:\dmd2\bin..\src\druntime\import"
LINKCMD="c:\dmd2\bin....\dm\bin"
DDOCFILE=mysettings.ddoc

This enables your dmd setup to be moved around without having to re-edit sc.ini.

Common Installation Problems

• Using Cygwin's unzip utility has been known to cause strange problems.
• Running the compiler under Cygwin's command shell has been also known to cause problems. Try getting it to work under the regular Windows shell cmd.exe before trying Cygwin's.
• Installing dmd and dmc into directory paths with spaces in them causes problems.

---

Differences between Windows and Linux versions

• String literals are read-only under Linux. Attempting to write to them will cause a segment violation.

---

D Interface Files

When an import declaration is processed in a D source file, the compiler searches for the D source file corresponding to the import, and processes that source file to extract the information needed from it. Alternatively, the compiler can instead look for a corresponding D interface file. A D interface file contains only what an import of the module needs, rather than the whole implementation of that module.

The advantages of using a D interface file for imports rather than a D source file are:

• D interface files are often significantly smaller and much faster to process than the corresponding D source file.
• They can be used to hide the source code, for example, one can ship an object code library along with D interface files rather than the complete source code.

D interface files can be created by the compiler from a D source file by using the -H switch to the compiler. D interface files have the .di file extension. When the compiler resolves an import declaration, it first looks for a .di D interface file, then it looks for a D source file.

D interface files bear some analogous similarities to C++ header files. But they are not required in the way that C++ header files are, and they are not part of the D language. They are a feature of the compiler, and serve only as an optimization of the build process.

Building Executables

dmd can build an executable much faster if as many of the source files as possible are put on the command line.

Another advantage to putting multiple source files on the same invocation of dmd is that dmd will be able to do some level of cross-module optimizations, such as function inlining across modules.

The -i flag can be used to automatically compile imported modules

Building Libraries

There are three ways to build a library. For example, given foo.d and bar.d which are to be compiled, and existing object file abc.obj and existing library def.lib which are all to be combined into a library foo.lib:

1. Compile modules separately and then run the librarian on them:

   dmd -c foo.d
   dmd -c bar.d
   phobos.lib -c -p32 foo.lib foo.obj bar.obj abc.obj def.lib
   del foo.obj bar.obj
   

   This option is typical when using a makefile to avoid compiling modules that have already been compiled.
2. Compile modules together and then run the librarian on them:

   dmd -c foo.d bar.d
   phobos.lib -c -p32 foo.lib foo.obj bar.obj abc.obj def.lib
   del foo.obj bar.obj
   

3. Use dmd to compile and build library in one operation:

   dmd -lib foo.d bar.d abc.obj def.lib
   

   No object files are written to disk, it's all done in memory. Using -lib also has the advantage that modules may be compiled into multiple object files rather than exactly one per module. This improves granularity of the library without having to break up the modules.

)