By default all versions of GridLAB-D use GNU compilers to build runtime classes. The only exception is when the MSVC debugger is selected, at which point GridLAB-D uses the MSVC compilers and linker.
As of Keeler (Version 4.0)
Runtime classes are supporting using the same compiler and debugging environment used to build GridLAB-D. Please consult the MinGW/Eclipse Installation page for information on installing the required tools for your environment.
Prior to Keeler (Version 4.0)
On most Linux systems it is not necessary to install compilers because they are usually already installed. There are some exceptions, such as installs of non-development workstations are most Mac OSX systems. However, it is generally easy to find and install the compilers for any Linux system. We do not provide further guidance here as the methods vary widely with each platform and are generally well documented.
The debugger of choice on Linux systems is unfortunately gdb. There are other X-based debuggers around, but we have very little experience using them with GridLAB-D.
On Windows systems it is necessary that you install the MinGW option when you install GridLAB-D. Without this option, runtime classes will not be supported and many sample programs will not run.
If you want to debug runtime class C++ code, we strongly recommend you use MS Visual Studio 2005TM. There is a GNU debugger (gdb) is available for use with GridLAB-D, but it is far less easy to work with than MS Visual Studio's debugger and has some significant shortcomings.
To use the MSVC debugger, you must include the debugger configuration file by adding the command
.glm. Otherwise, the compiler will assume you are use gdb.
If you run into trouble with runtime classes, we recommend turning on GridLAB-D's verbose output option. This provide additional information that can help diagnose the problem. This can be done either by using the
--verbose command line option or by adding the directive
Be aware than on Linux system, elements in the path list are separated by colons, and on Windows they are separate by semicolons.
Usually problems are related to how the environment variables PATH, INCLUDE, LIB are set, or how the include parameter is defined for the compiler command. The following are almost always required
#setenv PATH=path-to-gnutool-bins #setenv INCLUDE=path-to-gnutool-includes #setenv LIB=path-to-gnutool-libs
The define of the include variable shouldn't be necessary, but often is because the file
rt/gridlabd.h is needed to compile runtime code when the environment is not set up in the usual manner, and the search path to the
rt folder cannot be automatically resolved. If you need to define the path to the C headers, use the directive
C++ implementation debugging options
- Set this global variable to a non-null value to disable debugger line references to the GLM file. This can be useful when the debugger is not able to open the GLM file or when you want to debug the runtime classes C++ implementation directly. That can be used in conjunction with GRIDLABD_DEBUG, which keeps the C++ implementation file after the shared library is built. This is usually added to the command line as -D noglmrefs=1.
- Set this global variable to a non-null value to force all runtime implementation files to be recompiled every time the GLM file is loaded. This is usually added to the command line as -D force_compile=1.
DEPRECATED AS OF 4.0
- Enable compilation using MSVC.
- Enable the use of GDB to debug the runtime implementation. This preserves the C++ implementation files and start the gdb debugger using the gdb_window command. Note: this is not compatible with the Eclipse debugging environment.
- Specifies the environment in which runtime debugging is to be run. Note: this is not compatible with the Eclipse debugging environment.