Improve this page Quickly fork, edit online, and submit a pull request for this page. Requires a signed-in GitHub account. This works well for small changes. If you'd like to make larger changes you may want to consider using local clone. Page wiki View or edit the community-maintained wiki page associated with this page.

DMD Compiler for Linux

Requirements and Downloads

  1. Download D Compiler
  2. 32 bit x86 and 64 bit x86-64 Linux operating system
  3. Gnu C compiler (gcc)

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/samples/d/
Sample D programs
dmd2/linux/bin/dmd
D compiler executable
dmd2/linux/bin/dumpobj
Elf file dumper
dmd2/linux/bin/obj2asm
Elf file disassembler
dmd2/linux/bin/shell
Simple command line shell
dmd2/linux/bin/dmd.conf
Global compiler settings (copy to /etc/dmd.conf)
dmd2/linux/lib/libphobos2.a
D runtime library (copy to /usr/lib/libphobos2.a)

Installation

  • Unzip the archive into your home directory. It will create a ~/dmd directory with all the files in it. All the tools are command line tools, which means they are run from a console window.
  • Copy dmd.conf to /etc: 
    cp dmd2/linux/bin/dmd.conf /etc
  • Put dmd2/linux/bin on your PATH, or copy the linux executables to /usr/local/bin
  • Copy the library to /usr/lib: 
    cp dmd2/linux/lib/libphobos2.a /usr/lib

    • Compiler Arguments and Switches

    dmd files... -switches...
    files...
    File Extensions
    Extension File Type
    none D source files
    .d D source files
    .dd Ddoc source files
    .di D interface files
    .o Object files to link in
    .a Object code libraries to search
    @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 (#).
    -c
    compile only, do not link
    -color=on|off
    Show colored console output. The default depends on terminal capabilities.
    • on: always use colored output. Same as -color
    • off: never use colored output.
    -cov

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

    dmd -cov -unittest myprog.d
    -cov=nnn
    Perform code coverage analysis, generate .lst file with report, and error at runtime if code coverage is less than nnn% of the executable lines. This can be integrated into the build test process to ensure minimum unit test coverage.
    -D
    generate documentation from source
    -Dddocdir
    write documentation file to docdir 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.
    -dw
    treat use of deprecated features and attributes as warnings (this is the default)
    -de
    treat use of deprecated features and attributes as errors
    -debug
    compile in debug code
    -debug=level
    compile in debug level <= level
    -debug=ident
    compile in debug identifier ident
    -debuglib=libname
    Link in libname as the default library when compiling for symbolic debugging instead of libphobos2.a. 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 libphobos2.a. If libname is not supplied, then no default library is linked in.
    -deps=filename
    write module dependencies as text to filename
    -fPIC
    generate Position Independent Code (which is used for building shared libraries).
    -g
    add Dwarf symbolic debug info with D extensions for debuggers such as ZeroBUGS
    -gc
    add Dwarf symbolic debug info in C format for debuggers such as gdb
    -gs
    always generate standard stack frame
    -H
    generate D interface file
    -Hddir
    write D interface file to dir directory. -op can be used if the original package hierarchy should be retained
    -Hffilename
    write D interface file to filename
    --help
    print brief help to console
    -Ipath
    where to look for imports. path is a ; separated list of paths. Multiple -I's can be used, and the paths are searched in the same order.
    -ignore
    ignore unsupported pragmas
    -inline
    inline expand 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.
    -Jpath
    where to look for files for ImportExpressions. This switch is required in order to use ImportExpressions. path is a ; separated list of paths. Multiple -J's can be used, and the paths are searched in the same order.
    -Llinkerflag
    pass linkerflag to the linker, for example, -L-M
    -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.
    -m32
    compile a 32 bit executable. This is the default for the 32 bit dmd.
    -m64
    compile a 64 bit executable. This is the default for the 64 bit dmd.
    -main
    Add a default main() function when compiling. This is useful when unittesting a library, as it enables the user to run the unittests in a library without having to manually define an entry-point function.
    -man
    open browser specified by the BROWSER environment variable on this page. If BROWSER is undefined, x-www-browser is assumed.
    -map
    generate a .map file
    -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.
    -noboundscheck
    turns off all array bounds checking, even for safe functions. Deprecated (use -boundscheck=off instead).
    -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.
    -odobjdir
    write object files relative to directory objdir instead of to the current directory. -op can be used if the original package hierarchy should be retained
    -offilename
    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
    normally the path for .d source files is stripped off when generating an object, interface, or Ddoc file name. -op will leave it on.
    -profile
    profile the runtime performance of the generated code
    -property
    enforce use of @property on property functions
    -quiet
    suppress non-essential compiler messages
    -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.
    -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 .o or executable file is left behind.
    -shared
    generate shared library
    -unittest
    compile in unittest code, turns on asserts, and sets the unittest version identifier
    -v
    verbose
    -version=level
    compile in version level >= level
    -version=ident
    compile in version identifier ident
    -vtls
    print informational messages identifying variables defaulting to thread local storage. Handy for migrating to shared model.
    -w
    enable warnings
    -wi
    enable informational warnings (i.e. compilation still proceeds normally)
    -X
    generate JSON file
    -Xffilename
    write JSON file to filename

    Linking

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

    The actual linking is done by running gcc. This ensures compatibility with modules compiled with gcc.

    Environment Variables

    The D compiler dmd uses the following environment variables:

    CC
    dmd normally runs the linker by looking for gcc along the PATH. To use a specific linker instead, set the CC environment variable to it. For example:
    set CC=gcc
    BROWSER
    This sets the browser used to open the manual page with the -man switch. It defaults to x-www-browser.
    DFLAGS
    The value of DFLAGS is treated as if it were appended to the command line to dmd.

    dmd.conf Initialization File

    The dmd file dmd.conf is the same as sc.ini for Windows, it's just that the file has a different name, enabling a setup common to both Windows and this system to be created without having to re-edit the file.

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

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

    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.

    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: 

    ; dmd.conf 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]

DFLAGS=-I%@P%/../src/phobos -I%@P%/../src/druntime/import

    Differences between Windows and Linux versions

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

    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.o and existing library def.a which are all to be combined into a library foo.a:

    1. Compile modules separately and then run the librarian on them: 
      dmd -c foo.d
dmd -c bar.d
rm -f foo.a
ar -r foo.a foo.o bar.o abc.o def.a
rm foo.o bar.o
      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
rm -f foo.a
ar -r foo.a foo.o bar.o abc.o def.a
rm foo.o bar.o
    3. Use dmd to compile and build library in one operation: 
      dmd -lib foo.d bar.d abc.o def.a
      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.

    Compiling dmd

    Complete source code is provided to build the compiler. Follow these steps:

    cd ~/dmd2/src/dmd
make -f posix.mak

    Compiling Phobos

    Complete source code is provided to build Phobos, the D runtime library. Follow these steps:

    cd ~/dmd2/src/druntime
make -f posix.mak DMD=~/dmd2/linux/bin/dmd
cd ../phobos
make -f posix.mak DMD=~/dmd2/linux/bin/dmd