Let’s pick that phrase apart bit by bit.

A static object is one that exists from the time it’s constructed until the end of the program. Stack and heap-based objects are thus excluded. Included are global objects, objects defined at namespace scope, objects declared static inside classes, objects declared static inside functions, and objects declared static at file scope. Static objects inside functions are known as local static objects (because they’re local to a function), and the other kinds of static objects are known as non-local static objects. Static objects are automatically destroyed when the program exits, i.e., their destructors are automatically called when main finishes executing.

A translation unit is the source code giving rise to a single object file. It’s basically a single source file, plus all of its #include files.

The problem we’re concerned with, then, involves at least two separately compiled source files, each of which contains at least one nonlocal static object (i.e., an object that’s global, at namespace scope, or static in a class or at file scope). And the actual problem is this: if initialization of a non-local static object in one translation unit uses a non-local static object in a different translation unit, the object it uses could be uninitialized, because the relative order of initialization of non-local static objects defined in different translation units is undefined.

An example will help. Suppose you have a FileSystem class that makes files on the Internet look like they’re local. Since your class makes the world look like a single file system, you might create a special object at global or namespace scope representing the single file system:

class FileSystem {  // from your library’s header file  
public:  
  ...  
  std::size_t numDisks() const;  // one of many member functions  
  ...  
};  
extern FileSystem tfs;  // declare object for clients to use;  
 // (“tfs” = “the file system”);definition  
 // is in some.cpp file in your library  

A FileSystem object is decidedly non-trivial, so use of the tfs object before it has been constructed would be disastrous.

Now suppose some client creates a class for directories in a file system. Naturally, their class uses the tfs object:

class Directory {   // created by library client  
public:  
  Directory( params );  
  ...  
};  
Directory::Directory( params )  
{  
  ...  
  std::size_t disks = tfs.numDisks();  // use the tfs object  
  ...  
} 

Further suppose this client decides to create a single Directory object for temporary files:

Directory tempDir( params );   // directory for temporary files 

Now the importance of initialization order becomes apparent: unless tfs is initialized before tempDir, tempDir’s constructor will attempt to use tfs before it’s been initialized. But tfs and tempDir were created by different people at different times in different source files — they’re non-local static objects defined in different translation units. How can you be sure that tfs will be initialized before tempDir