Home » SSTDocumentation » SST Developer FAQ

SST Developer FAQ

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.

What is the recommended platform for SST?

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

CentOS
Ubuntu
TOSS
RedHat
Mac OSX

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.

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:

Verify that the same explicit compiler (both type and version) is used throughout the build process. For example, if “/usr/bin/gcc” and “/usr/bin/g++” is the desired C and C++ compiler set, confirm that these are used to build each item. Various external packages probe for a compiler, and may not find the exact same compiler set. Always verify that the same compiler set is consistently used to build SST. Many packages respect the “CC” and “CXX” environment variables (for the C and C++ compiler, respectively) that allow users to force selection of a particular compiler to do the build.

On MacOS:

On MacOS, the compiler choices can vary greatly based upon the version of Apple developer tools installed.

1) In recent 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.

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

What C++ standard does SST support?

As of SST 12.0, the SST project supports C++11. We anticipate future releases will add C++14 support.

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

If there is no .unignore file, a .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.

Check out the mainline on a host.

$ git clone git clone --recursive https://github.com/sstsimulator/sst.git
$ cd sst
$ git submodule foreach git checkout devel

Run autogen and configure SST (it needs to have a minimal config).

$ cd sst-simulator
$ ./autogen.sh
$ ./configure --disable-silent-rules --prefix=$HOME/local/

Build Doxygen HTML documentation (~60 MB)

$ make html

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.
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 top-level directory usually suffices. If “.am” or “.m4” files are modified, first execute ./autogen.sh and then do a configure. The configure line can be copied from the config.log file located in the top-level directory. Then do “make install”. There are some issues in the elements, particularly Ariel’s pintool, where changes may require a “make clean”. This can usually be run in the element directory for the element that is causing trouble to avoid having to do a full rebuild.