我们正在使用泛型编译一个软件，其中文件首先被制作成目标文件，它们是这样构建的：
public: using B::var然后他们与：
联系在一起arm-unknown-linux-gnu-gcc -c -O2 -Wstrict-prototypes -Wdeclaration-after-statement -fsigned-char -I/opt/tm-sdk/include -mlittle-endian -Wno-trigraphs -fno-strict-aliasing -fno-omit-frame-pointer -march=armv4 -mtune=arm9tdmi -Wall -Wextra -o src/flex.o src/flex.c
...
arm-unknown-linux-gnu-gcc -c -O2 -Wstrict-prototypes -Wdeclaration-after-statement -fsigned-char -I/opt/tm-sdk/include -mlittle-endian -Wno-trigraphs -fno-strict-aliasing -fno-omit-frame-pointer -march=armv4 -mtune=arm9tdmi -Wall -Wextra -o src/flexdb.o src/flexdb.c
我的问题是： 我们是否需要在链接期间包含优化和警告标志？如果在从目标文件创建flex二进制文件时包含-Wall，-Wextra和-O2，它会做什么。
谢谢
编辑：根据反馈澄清意义。
答案 0 :(得分：5)
在编译的最后阶段，我们是否需要包含优化和警告标志？
当然，你不需要将它们包含在链接阶段。您已经知道，因为不包含它们。但我认为你真正想知道的是......
如果在从目标文件构建flex二进制文件时包含了-Wall，-Wextra和-O2，它会做什么。
在编译阶段生成所有或几乎所有警告。我不知道任何例外，但可以想象有一些例外。因此，在链接期间传递与警告相关的标志可能会触发警告，否则您将无法收到警告。但这不应该以任何方式影响编译的二进制文件。
优化是不同的。可以在链接时执行优化，但可能不会在默认优化级别执行。从链接命令中省略优化标志不应该破坏您的构建，但包含它们可能会导致更快和/或更小的二进制文件。
总的来说，我认为没有充分的理由避免在编译步骤中执行的链接步骤中传递相同的警告和优化标志。如果您愿意，传递预处理器特定的标志（例如df <- data.frame(alphabets1=c("A","B","C","B","C"," ",NA),
alphabets2=c("B","A","D","D"," ","E",NA),
alphabets3=c("C","F","G"," "," "," ",NA),
number = c("1","2","3","1","4","1","2"))
）也没有坏处，因为它们在链接期间只会被忽略。我认为所有这些都是由-D管理的，所以你不一定每次都要输入选项。
答案 1 :(得分：0)
不，您只是在最后调用gcc时调用链接器，而-W和-O标志用于编译器。
答案 2 :(得分：-4)