Почему изменение порядка связывания исправляет некоторые ошибки связывания в одной системе?

Правильное решение этого в CMake это не корректировать порядок вручную, а точнее моделировать взаимозависимости между различными целями.

Точный характер зависимости порядка здесь зависит от цепочки инструментов (на gcc зависимые должны располагаться раньше зависимостей в командной строке компоновщика; MSVC это не волнует; другие цепочки инструментов могут выбирать другие требования к порядку). Единственный способ для CMake убедиться, что он генерирует правильный порядок для данной цепочки инструментов, — это явное моделирование зависимостей в CMake.

В вашем примере вы смоделировали плоский список зависимостей:

target_link_libraries(${PROJECT_NAME}_test PRIVATE Threads::Threads -lglog -lpthread
${QT_LIBRARIES}
${OpenCV_LIBRARIES}
${PROJECT_BINARY_DIR}/googletest-build/googlemock/libgmock.a
${PROJECT_BINARY_DIR}/googletest-build/googlemock/gtest/libgtest.a
)

У вас есть одна цель ${PROJECT_NAME}_test это зависит от нескольких библиотек. Но это на самом деле неправильно! На самом деле, есть зависимость от gmock от gtest, о которой вы не сказали CMake. Вам нужно смоделировать эту зависимость явно, чтобы CMake работал правильно. Поскольку зависимости могут быть указаны только между целями, нам нужно ввести две дополнительные цели для gtest и gmock:

add_library(gtest INTERFACE)
target_link_libraries(gtest INTERFACE ${PROJECT_BINARY_DIR}/googletest-build/googlemock/gtest/libgtest.a)
add_library(gmock INTERFACE)
target_link_libraries(gmock INTERFACE ${PROJECT_BINARY_DIR}/googletest-build/googlemock/libgmock.a)
target_link_libraries(gmock INTERFACE gtest)   # now gmock depends on gtest

target_link_libraries(${PROJECT_NAME}_test PRIVATE Threads::Threads -lglog -lpthread
${QT_LIBRARIES}
${OpenCV_LIBRARIES}
gtest
gmock     # order doesn't matter here;
# you can even omit gtest completely now
)

Обратите внимание target_link_libraries позвоните сюда, который устанавливает зависимость от gmock в gtest, Очень важно всегда моделировать прямые зависимости между статическими библиотеками, подобными этим, в CMake, в противном случае вы получите проблемы, подобные той, что вы описали, которая может быстро перерасти вашу голову, как только ваша сборка превысит определенную сложность.

В качестве примечания постарайтесь не жестко кодировать пути к библиотекам в файлах CMake, так как это снова делает вашу сборку непереносимой и может полностью сломаться на разных наборах инструментов.