为gcc/g++；

我很想知道，通过以下两种方式（CC可以是g++或gcc）将库（共享库和静态库）指定给gcc/g++是否有实质性的区别

vs

我只能看到一个主要区别，即直接传递完全指定的库名称将有助于在选择静态或动态版本时获得更大的控制权，但我怀疑还有其他事情会对可执行文件的构建方式或运行时的行为产生副作用，对吗

---

Andrea.

好的，我可以根据一些实验和对gcc文档的深入阅读来回答自己：

根据gcc文件：

[…]链接器通过扫描归档文件中定义符号的成员来处理归档文件，这些符号到目前为止已被引用但尚未定义。但是，如果找到的文件是普通对象文件，则会以常规方式链接该文件。使用-l选项和指定文件名之间的唯一区别是-l使用

lib”和
.a”包围库，并搜索多个目录

这实际上也回答了关于在gcc命令行上直接指定目标文件的第三个选项的相关疑问（即，在这种情况下，目标文件中的所有代码都将成为最终可执行文件的一部分，而使用归档文件时，只有真正需要的目标文件才会被拉入）.
您是否尝试了这两种方法并比较了生成的可执行文件？不太可能。这可能是我的下一个测试，尽管我更愿意在使用完整路径时查看是否有关于此的“官方”信息。那么-在不同环境下运行时会发生什么？被人查起来怎么样？它似乎将整个字符串作为一个库进行搜索，因此，如果它不存在于目标环境中的原始确切位置中，则无法找到它。。如何克服这个问题？如果.so有一个“soname”（即添加了主要版本号的库名），通常会发生的情况是，“soname”在可执行文件中注册为依赖项。然后，在启动可执行文件时，运行时链接器（linux上通常为/lib/ld linux.so.X）将查找soname（通常在文件系统上是指向.so实名的符号链接）的不同位置（由平台、ld_LIBRARY_PATH环境变量以及可能在构建过程中使用的rpath参数确定）。也请看，谢谢！几个小时前发现了soname和rpath自己：）
CC -o output_executable /path/to/my/libstatic.a /path/to/my/libshared.so source1.cpp source2.cpp ... sourceN.cpp

CC -o output_executable -L/path/to/my/libs -lstatic -lshared source1.cpp source2.cpp ... sourceN.cpp