When building LibreOffice on Snapcraft (both 1.0.2/wily and 2.2.2/xenial) additional include paths are injected into the environment by setting CFLAGS environment. This works for the trivial case to find a unique header that is just at a different location. However, headers do not have unique names, the order of include header locations is relevant. In case of LibreOffice, this causes the compiler to pick up the nss.h header from glibc instead of the nss.h header from Mozillas Network Security Services resulting in a compile time error. Currently, I am working around this by completely overriding the rules for the breaking compilation units with a hardcoded rule that orders the include paths properly, but which in its current form would be quite a maintainability burden. Beyond the concrete problem (nss.h for some LibreOffice compilation units), please note that in this case we are lucky that the fumbled include path precedence results in a compile time error. Its easy to see that there might be other, apparently more trivial headers (e.g. something declaring some common typedefs for integer types) that _compile_ just fine when picking up the wrong header, but fail in subtle and nasty ways at runtime.