GCC 命令行参数挑剔 [英] GCC Command-Line Argument Pickiness

问题描述

GCC 可以对它接受参数的顺序非常挑剔:

GCC can get pretty picky about the order in which it accepts its arguments:

# Works.
g++ Foo.cpp -L. -I. -lBar -o Foo

# Linker errors.
g++ -o Foo -I. -L. -lBar Foo.cpp

具体来说，命令行选项的排序要求是什么?

What, specifically, are the ordering requirements for command-line options?

推荐答案

库是根据需要的符号按需加载的，因此提供其他东西所需符号的库必须遵循其他东西.这是历史性的；可以说，现代系统应该自动解析符号，明智地处理循环(这就是规则的原因；您通过按顺序指定库并根据需要多次手动破坏依赖循环)，但是 g++ 遵循传统规则，因此它适用于供应商 ld.(GNU ld 并非在任何地方都有效，因此不可能依靠它来解决符号依赖循环.即使在 GNU ld 确实有效.)类似地，其他面向链接器的选项必须以相对于它们所影响的事物的正确顺序指定(例如，-L 选项必须位于位于指定目录中的库之前; 如果一个目录中的库隐藏了标准目录中的同名库，这可能很重要).

Libraries are loaded on demand based on the symbols required from them, so the library which provides a symbol needed by something else must follow that something else. This is historical; arguably a modern system should resolve symbols automatically, handling loops sensibly (that being the reason for the rule; you broke dependency cycles manually by specifying libraries in order and as many times as needed), but g++ follows the traditional rule so it will work with vendor lds. (GNU ld doesn't work everywhere, so it wouldn't be possible to rely on it to resolve symbol dependency loops. There are also bootstrapping concerns even on platforms where GNU ld does work.) Similarly, other linker-oriented options must be specified in the correct order relative to the things they affect (for example, a -L option must precede a library which lives in the specified directory; this can be important if a library in one directory shadows a library of the same name in a standard directory).

这篇关于GCC 命令行参数挑剔的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！