SST Developer FAQ

This page collects short tidbits of information that may be useful to know.

What is the development workflow for SST?

See Development Workflow for more details.

We attempt to build and test SST on a variety of Linux and MacOS X platforms (See the latest release notes) for more details.

Unfortunately, due to a variety of constraints, we are unable to confirm successful operation of SST on platforms beyond those stated above. We have sought to select the most popular and widely available platforms for our development and testing. It is likely that SST will build and run successfully on platforms other than those listed, but if a user should attempt to build and run SST on an unverified platform, they may encounter unforseen difficulties or incompatibilities particular to the toolsets installed on that platform. If there is enough interest to justify supporting a particular configuration, the SST team will consider adding it to the group of testbeds. Otherwise, users who wish to use SST on an unverified platform should direct their questions to the SST mailing list where the SST developer community can attempt to address their issues.

What older tool and compiler version must be supported for Release 5.1

For additions or enhancements to be included in release 5.1, code must be back compatible with gcc-4.4.7 and Python scripts was be acceptable to Python 2.6.

Why am I getting linking errors when I build SST?

This is typically due to an inconsistency in the toolchain. Each item must be built using the same compiler. If the same compiler is not used consistently in an SST build, a binary incompatibility situation can arise due to the objects using different C++ runtimes.

On Linux:

On MacOS:

1) In some versions of Xcode, a full Apple-enhanced GNU compiler set is included, “Apple-enhanced” meaning that the Apple variant of the GNU compiler supports options that the associated baseline GNU version of the compiler does not.

2) In later versions of Xcode, the Apple-enhanced GNU compiler is dropped in favor of wrappers (called “gcc” and “g++”) that invoke the LLVM clang and clang++ compilers. This case in particular can cause confusion for those who are unaware of the wrappers. The wrappers can mislead users into thinking that they are using a GNU compiler when they are not. These wrappers are not fully compatible with a real GNU compiler set.

3) If MacPorts GNU compilers are installed and are to be used, ensure that the PATH environment variable is set so that the correct MacPorts gcc and g++ compilers are invoked for the entire build. Also, it is important to be aware that some packages detect a GNU compiler, but wrongly assume that it is the Apple-enhanced GNU compiler. These packages will require additional configuration so that they supply only generic GNU options and flags to the compiler instead of options and flags that are only supported on the Apple-enhanced GNU compiler.

4) When building OpenMPI, understand that the resultant mpicc and mpicxx files are compiler wrappers also. It is important that mpicc and mpicxx wrap the same compiler that is used for the entire build. OpenMPI is used to build Boost and Boost MPI libraries, and if OpenMPI is built such that it wraps the wrong compiler, these libraries will be incompatible with the rest of SST, and linking errors will ensue.

Does SST support the C++11 standard?

The SST project is currently transitioning to the new C++11 standard, but this transition is not complete and support is still required for older platforms and compilers where the C++11 is not fully implemented. During configure, SST checks various compiler features and enables C++ defines and Automake Macros for element libraries to use. ‘‘Component writers adding to the code base should use these macros to guard any C++11 code. Use of these macros will prevent non-compliant compilers and platforms from failing.’’

What are the .ignore and .unignore files and how are they used?

If there is no .unignore file, an .ignore file simply is a flag to ignore, in the SST build, the subtree it resides in. It can be checked in to Git to allow code under development to reside in the repository without impacting either the nightly builds or other developers.

The .unignore file overrides the .ignore file, but can do so conditionally based on the user name doing the build. If there is no existing, .unignore file creating one overrides the .ignore, but no change shows up in an “git diff”.

To permanently override the .ignore, just for just a particular user, add a line containing that user name to the .unignore file. This .unignore file can be checked in to Git to make the conditional override permanent.

To permanently override the .ignore, the .ignore file should be deleted rather than having an .ignore file and universal .unignore file.

How do I create the Doxygen output?

Note that the Doxygen output from the development trunk of SST is viewable Here.

  1. Check out the mainline on a host.
$ git clone git clone --recursive
$ cd sst
$ git submodule foreach git checkout devel
  1. Run autogen and configure SST (it needs to have a minimal config). $BOOST_HOME should point to a convenient Boost installation, even though it isn’t used for the documentation build.
$ cd sst-simulator
$ ./
$ ./configure --disable-silent-rules --prefix=$HOME/local/ --with-boost=$BOOST_HOME
  1. Build Doxygen HTML documentation (~60 MB)
$ make html
  1. HTML documentation will be generated in sst-simulator/doc/html. It may be necessary to copy this html directory to a system that has a web browser, such as a laptop.
  2. With a web browser application, open html/index.html

Can I do a partial rebuild of an edited source tree?

Assuming LD_LIBRARY_PATH is set and modules are loaded as required for execution, do the following: If only source code is modified, a “make install” from the “trunk” directory usually suffices. If “.am” or “.m4” files are modified, first execute ./ and then do a configure. The configure line can be copied from the config.log file located in the trunk. Then do “make install”. There are some issues in the elements, portals4 and portals_sm, which if changes are made there may require first doing a “make clean” from the “trunk”, followed by the autogen and configure. (Hopeful you don’t discover additional places where the autotools scripts aren’t quite right.)