向 gcc/g++ 指定库的不同方法
我很想知道通过以下两种方式（CC 可以是 g++ 或 gcc）向 gcc/g++ 指定库（共享库和静态库）是否有任何实质性区别，
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
我只能看到主要区别是直接传递完全指定的库名称可以更好地控制选择静态或动态版本，但我怀疑还有其他事情可能会对可执行文件的构建方式或运行时的行为产生副作用，对吗？
安德里亚.
I'd be curious to understand if there's any substantial difference in specifying libraries (both shared and static) to gcc/g++ in the two following ways (CC can be g++ or gcc)
CC -o output_executable /path/to/my/libstatic.a /path/to/my/libshared.so source1.cpp source2.cpp ... sourceN.cpp
vs
CC -o output_executable -L/path/to/my/libs -lstatic -lshared source1.cpp source2.cpp ... sourceN.cpp
I can only see a major difference being that passing directly the fully-specified library name would make for a greater control in choosing static or dynamic versions, but I suspect there's something else going on that can have side effects on how the executable is built or will behave at runtime, am I right?
Andrea.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好的，我可以根据一些实验和对 gcc 文档的更深入阅读来回答自己：
来自 gcc 文档： http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
这实际上也回答了有关第三个选项的相关疑问在 gcc 命令行上直接指定目标文件（即在这种情况下，目标文件中的所有代码都将成为最终可执行文件的一部分，而使用存档时，只有真正需要的目标文件才会被拉入）。
Ok, I can answer myself basing on some experiments and a deeper reading of gcc documentation:
From gcc documentation: http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
This actually answers also to the related doubt about the 3rd option of directly specifying object files on the gcc command line (i.e. in that case all the code in the object files will become part of the final executable, while using archives, only the object files that are really needed will be pulled in).