我在Linux上看到了一个奇怪的链接问题，它使用了一个跨平台的库项目，它使用CMake从同一个源码树创build一个OS X Framework和一个Linux共享库。 该项目的跨平台方面在过去（两年前左右）运行良好，但从那以后，我们专门在OS X上进行了开发工作。暂时放弃Linux的原因是开发人员短缺：所有那些仍然使用OS X的人 – 没有任何技术上的原因，在Linux上build立多年的源码。
有一个潜在的相关例外（稍后会有更多的例外），同时我们的来源也没有根本性的变化。 当然，Linux已经进步了，当然，当我们回到那里的时候，当然也有一些小的障碍。 像新版本的编译器抱怨过去没有抱怨过的事情（可疑的转换，void Voodoo等等）。 这些问题在短期内得到解决。
整个源代码树现在在Mint 17.1上再次编译，并带有一些绝对无害的剩余警告。 但是，连接失败了一个相当奇怪的信息：
Linking CXX shared library lib<ourLibName>.so CMakeFiles/<file1>.co:1:1: error: stray '\177' in program CMakeFiles/<file1>.co:1:1: error: stray '\2' in program CMakeFiles/<file2>.co:1:1: error: stray '\213' in program (and so on, thousands of times, with seemingly random values in the quotes for all the object files in the library) 对我来说，这看起来像链接器意外地试图再次编译目标文件，而不是链接它们。 在gcc和clang之间切换没有任何区别。
正如我已经说过的那样，这个项目自上次在Linux下编译以来，有一个潜在的相关结构变化：它曾经是只有C和Objective-C源代码的组合。 它现在包含C，Objective-C 以及Objective-C ++源代码。 在OS X上，这个改变并没有引起什么问题，我很难想象这个.mm文件的增加会导致我们在这里看到的东西。 但仍然是奇怪的事情发生了。
另外，在C / C ++程序中错误地包含unicode字符的一些关于stackoverflow的文章也很stream行。 这不是问题 – 在实际编译期间不会出现这样的消息。 一旦链接发生，马戏团才会开始。
源码树太大而不能发布，CMake文件也相当复杂，嵌套和大（即不可能在这里包括）。 为了增加伤害，在Ubuntu 10.10上，他们过去一直很好。 我再也没有这个东西了，来testing一下当前的树是否仍然在那里工作（我想这可能太简单了）。 在CMakeList中生成Linux下的库的相关命令是
set_target_properties( <ourLibName> PROPERTIES VERSION 2.0 SOVERSION 2 ) target_link_libraries( <ourLibName> ${our_other_link_libraries} ) install ( TARGETS <ourLibName> DESTINATION lib )
乍一看对我来说依然如此。 我如何在这里继续？ 我不知道下一步该怎么做。
涉及软件的PS版本：Cmake 2.8.11，gcc 4.8.2，铛3.4-1ubuntu3。
发现问题的根源很简单：一个已经不在我们面前的项目开发者显然是在一年或两年前尝试在Linux上构建Objective-C ++版本的源代码。 从他的失败尝试，在CMake编译器标志的仅Linux部分有一个明智的剩余：
else ( APPLE ) set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -x objective-c++" ) endif ( APPLE )
kicker当然是-x objective-c++标志。 这不会在编译过程中造成任何伤害，除非您得到大量不必要的警告。 但是，因为这些标志也被传递给链接器 ，所以它强制穷人将所有的目标文件当作ObjC ++输入。 该标志不应该在那里：CMake足够聪明，可以立即处理C，ObjC和ObjC ++的混合。 一旦标志被删除，一切按预期工作。