Firebase-cpp-sdk on Windows pulls in firebase-ios-sdk (for firestore code), which pulls in leveldb (for key/value persistence) and Snappy (for efficient data compression). For faster compression, Snappy uses one specific CPU instruction for bit manipulation, bzhi, from the BMI2 instruction set. However, this instruction crashes firestore on a CPU that does not support the BMI2 instructions, which is the case of older CPUs, for example Intel pre-Haswell and AMD pre-Excavator CPUs.

By default, Snappy detects if it should use the BMI2 optimized instruction by performing a compilation test on the cmake configure phase , which obviously returns if the build machine supports BMI2, not the target machines.
Snappy build setup does not support a compiler directive that overrides that specific compilation test, so it can only build for the host machine BMI2 setup.

Unfortunately, due to the very involved dependency chain, there is no good way to patch Snappy's code and the easiest solution in terms of maintenance is to patch the config.h created during the configure step, which is what this PR does. It only changes the automated build process (Github Actions workflow).

Firebase-cpp-sdk on Windows pulls in firebase-ios-sdk (for firestore code), which pulls in leveldb (for key/value persistence) and Snappy (for efficient data compression). For faster compression, Snappy uses one specific CPU instruction for bit manipulation, bzhi, from the BMI2 instruction set. However, this instruction crashes firestore on a CPU that does not support the BMI2 instructions, which is the case of older CPUs, for example Intel pre-Haswell and AMD pre-Excavator CPUs.

By default, Snappy detects if it should use the BMI2 optimized instruction by performing a compilation test on the cmake configure phase , which obviously returns if the build machine supports BMI2, not the target machines.
Snappy build setup does not support a compiler directive that overrides that specific compilation test, so it can only build for the host machine BMI2 setup.

Unfortunately, due to the very involved dependency chain, there is no good way to patch Snappy's code and the easiest solution in terms of maintenance is to patch the config.h created during the configure step, which is what this PR does. It only changes the automated build process (Github Actions workflow).

Firebase-cpp-sdk on Windows pulls in firebase-ios-sdk (for firestore code), which pulls in leveldb (for key/value persistence) and Snappy (for efficient data compression). For faster compression, Snappy uses one specific CPU instruction for bit manipulation, bzhi, from the BMI2 instruction set. However, this instruction crashes firestore on a CPU that does not support the BMI2 instructions, which is the case of older CPUs, for example Intel pre-Haswell and AMD pre-Excavator CPUs.

By default, Snappy detects if it should use the BMI2 optimized instruction by performing a compilation test on the cmake configure phase , which obviously returns if the build machine supports BMI2, not the target machines.
Snappy build setup does not support a compiler directive that overrides that specific compilation test, so it can only build for the host machine BMI2 setup.

Unfortunately, due to the very involved dependency chain, there is no good way to patch Snappy's code and the easiest solution in terms of maintenance is to patch the config.h created during the configure step, which is what this PR does. It only changes the automated build process (Github Actions workflow).

Firebase-cpp-sdk on Windows pulls in firebase-ios-sdk (for firestore code), which pulls in leveldb (for key/value persistence) and Snappy (for efficient data compression). For faster compression, Snappy uses one specific CPU instruction for bit manipulation, bzhi, from the BMI2 instruction set. However, this instruction crashes firestore on a CPU that does not support the BMI2 instructions, which is the case of older CPUs, for example Intel pre-Haswell and AMD pre-Excavator CPUs.

By default, Snappy detects if it should use the BMI2 optimized instruction by performing a compilation test on the cmake configure phase , which obviously returns if the build machine supports BMI2, not the target machines.
Snappy build setup does not support a compiler directive that overrides that specific compilation test, so it can only build for the host machine BMI2 setup.

Unfortunately, due to the very involved dependency chain, there is no good way to patch Snappy's code and the easiest solution in terms of maintenance is to patch the config.h created during the configure step, which is what this PR does. It only changes the automated build process (Github Actions workflow).

Firebase-cpp-sdk on Windows pulls in firebase-ios-sdk (for firestore code), which pulls in leveldb (for key/value persistence) and Snappy (for efficient data compression). For faster compression, Snappy uses one specific CPU instruction for bit manipulation, bzhi, from the BMI2 instruction set. However, this instruction crashes firestore on a CPU that does not support the BMI2 instructions, which is the case of older CPUs, for example Intel pre-Haswell and AMD pre-Excavator CPUs.

By default, Snappy detects if it should use the BMI2 optimized instruction by performing a compilation test on the cmake configure phase , which obviously returns if the build machine supports BMI2, not the target machines.
Snappy build setup does not support a compiler directive that overrides that specific compilation test, so it can only build for the host machine BMI2 setup.

Unfortunately, due to the very involved dependency chain, there is no good way to patch Snappy's code and the easiest solution in terms of maintenance is to patch the config.h created during the configure step, which is what this PR does. It only changes the automated build process (Github Actions workflow).