Setting up a development environment for hacking GDC

Iain Buclaw via D.gnu d.gnu at
Sun Oct 12 02:11:03 PDT 2014

On 12 October 2014 01:29, Mike via D.gnu <d.gnu at> wrote:
> I'm wondering, if some of you that do development on GDC could briefly
> describe how you set up your development environment.
> I can build GDC fine, but I can't do the 30-minute build for every little
> change.  The build script is just a black box to me right now.  How do you
> guys do incremental compile and debugging?  I've seen
>, but that doesn't help me with
> incremental compile.
> I could probably spend some time analyzing the build scripts and figure
> something out, but it would take me quite a while and I'd probably just end
> up with something non-ideal.
> So, please take a few minutes to give me the basic rundown.  If I can get
> set up, and if you think it would help, I'll give back by writing a wiki
> page on how to get set up from a beginner's perspective.
> Thanks,
> Mike

I should spend some time on this as well.  The basic run-down I can
give assumes you've just installed Ubuntu, or some other Debian-like

Install packages:

  apt-get install gcc g++ libmpc-dev libmpfr-dev libgmp3-dev
autoconf2.64 automake1.11 flex bison patch git

Source folder structure:

  . gdc/
  . . gcc-devel/  (or gcc-4.9 if you use a specific version)
  . . gdc/
  . . objdir/

I assume that you have checked out the git respository or downloaded a
tarball of the gdc/gcc sources and extracted them in their appropriate
place.  The objdir directory is the place where we will do the build

Setup GCC to build D:

The setup-gcc script creates all necessary symlinks and patches GCC to
be aware of the D frontend.

  cd gdc && ./ ../gcc-devel

Configure and Build:

  ../gcc-devel/configure --prefix=/usr --enable-languages=d
--enable-checking --disable-bootstrap --disable-libgomp
--disable-libmudflap --disable-libquadmath

If you are doing cross compilation you will have to tweak the --host,
--target, and --build switches to be correct.

To start building, simply run make with your preferred -j# number for
parallel builds.

Initial installation:

I prefer to keep all builds under ~/.local but you may have another
place to put it.

  DESTDIR=$HOME/.local make install

Then add the $DESTDIR/usr/bin location to your PATH.  For instance I
have the following in my ~/.bashrc folder

  if [ -d $HOME/.local/usr/bin ]; then
    export PATH="$HOME/.local/usr/bin:$PATH"

Incremental Builds:

When you make a change to either the gdc or gcc sources, running make
inside objdir will keep on doing incremental builds for you.  Some
exceptions to the rule:

* Adding/Removing files from libphobos or libdruntime require you to
re-run the script

  ./ --update ../gcc-devel

* I have noted in certain circumstances (updating the frontend
mostly), changes to dfrontend/idgen.c or dfrontend/impcnvgen.c
sometimes do not trigger rebuilds of other sources.  When this occurs,
crashes or errors will look rather confusing.  That's because the
symbol table between two object files differ. Clean out all objects
from the gdc build directory and re-make it.

Changes to just gdc only require a rebuild of cc1d - or the 'D compiler proper':

  make -C gcc cc1d

Changes to libphobos/libdruntime can be done using make:

  make all-target-libphobos

Incremental Installs:

Changes to just gdc just require the installation of cc1d:

  install gcc/cc1d $HOME/.local/usr/libexec/gcc/$TARGET/$VERSION

Changes to libphobos/libdruntime can be done using make:

  DESTDIR=$HOME/.local make install-target-libphobos

Clean Builds:

Cleaning out gdc / cc1d only (from the objdir):

  rm gcc/gdc gcc/d/*

Cleaning out libphobos/libdruntime:

  make clean-target-libphobos

Debugging GDC:

Though GCC does allow you to debug the compiler using -wrapper.  I
find it quicker to just pass --verbose

  gdc -pipe -c --verbose bug.d

This will print out the command used to invoke cc1d.  From there you
can copy it, and pass it to your favourite debugger and get cracking.

Noteworthy functions break at to catch ICE's:


Noteworthy functions to debug trees/gimple:


That's about it from a quick run-down side of things.

More information about the D.gnu mailing list