这是个非常典型的链接器符号解析顺序导致的问题，虽然你用了同一个Docker镜像，但本地Arch和CI的Ubuntu 16.04主机的底层环境差异，让原本隐藏的符号冲突在CI环境下触发了段错误。具体原因可以拆解为这几点：

1. 静态库链接的"顺序决定符号优先级" #

链接器处理静态库（.a文件）时，是严格按照你在target_link_libraries中指定的从左到右顺序来解析未定义符号的：

• 它会逐个扫描每个静态库，把当前还未找到定义的符号和库中的符号做匹配；
• 一旦找到匹配的符号，就会把该库中对应的目标文件加入最终的可执行文件；
• 如果后续的库中有同名符号，链接器不会替换已经解析完成的符号——也就是说，先出现的库中的符号会被优先选用。

你的场景里，${OpenCV_LIBRARIES}和gmock/gtest的静态库大概率存在同名符号（比如某些通用工具函数、甚至是STL相关的底层符号）。当你把gmock/gtest放在OpenCV前面时，链接器优先选用了gmock里的符号实现；反过来先链接OpenCV的话，就会用OpenCV的版本。这两个版本的符号实现可能存在兼容性问题，最终导致运行时段错误。

2. 同镜像不同主机的隐性差异 #

虽然Docker容器隔离了用户空间，但主机的以下差异可能影响链接器的行为：

• 内核版本差异：Arch Linux和Ubuntu 16.04的主机内核版本不同，可能导致链接器在处理符号重定位、内存布局时的细微差别；
• 链接器环境差异：即使是同一个gcc镜像，主机的链接器（ld）默认配置、甚至是LD_PRELOAD这类环境变量，都可能间接改变符号解析的优先级；
• Runner运行模式差异：本地Runner和CI Runner的运行环境可能存在资源限制、挂载差异，间接影响了链接器的工作逻辑。

本质上，符号冲突本来就存在，只是本地Arch的环境刚好让错误的符号实现没有触发段错误，而CI的Ubuntu环境让这个问题暴露了出来。调整链接顺序，其实是让链接器选择了和测试逻辑兼容的符号实现，避免了运行时的内存访问错误。

3. 验证符号冲突的小方法 #

如果你想确认这个猜测，可以在两个环境下分别用nm命令查看测试二进制的符号表：

nm -C your_test_executable | grep "疑似冲突的符号名"

对比输出结果，你会看到在不同链接顺序下，该符号对应的库来源（OpenCV或gmock/gtest）是不同的，这就能直接验证链接顺序的影响。

内容的提问来源于stack exchange，提问作者Phillipp Mevenkamp