Link Time Optimization (-flto) triggers static initialization bug in Open3D

[roehling]

Checklist

• I have searched for similar issues.
• For Python issues, I have tested with the latest development wheel.
• I have checked the release documentation and the latest documentation (for master branch).

Steps to reproduce the issue

I first cloned Open3D by:

git clone https://github.com/isl-org/Open3D.git
cd Open3D

Then, I build Open3D (on Debian Sid) with:

mkdir build
cd build
cmake -DCMAKE_INTERPROCEDURAL_OPTIMIZATION=ON ..
make -j$(nproc)

Error message

Build succeeds without error, but the Open3D GUI will fail to load materials at runtime.

Open3D, Python and System information

- Operating system: Debian unstable ("sid")
- Python version: Python 3.9
- Open3D version: 0.14.1
- System architecture: x86
- Is this a remote workstation?: no
- How did you install Open3D?: build from source
- Compiler version (if built from source): gcc 11

Additional information

I tracked the bug to a corrupted defaults_mapping::shader_mappings map. The map has static storage and depends on members of FilamentResourceManager, again with stattic storage. This creates a initialization order dependency across translation units, also known as the static initialization order fiasco, and will break Open3D if the static variables from FilamentResourceManager.cpp are not initialized before those in FilamentScene.cpp.

As initialization normally happens in the order the object files are linked, and (thanks to the alphabetic sorting) FilamentResourceManager.cpp comes before FilamentScene.cpp, this bug has not surfaced before. However, LTO seems to mess with the initialization order, thereby exposing the bug.

The static initialization order problem is usually avoided using the Construct On First Use idiom. For now, the bug can be mitigated by disabling/not enabling Link Time Optimization for the Open3D main library. The Python module is not affected and should be built with LTO for performance reasons, actually.