ar, nm, 和ranlib由 binutils 包提供。gcc-ar, gcc-nm, 和gcc-ranlib由 GCC 包提供。我在某处读到gcc-ar,gcc-nm和分别是,和二进制文件gcc-ranlib的“有效包装器” 。arnmranlib
gcc-ar、gcc-nm和gcc-ranlib与ar、nm和之间的技术区别是什么ranlib？GCC 在其构建中提供这些二进制文件一定是有原因的。
用户空间包的构建系统何时应该使用一个与另一个？如果用于构建用户空间包的工具链是基于 GCC 的，那么使用哪一个（例如arvs gcc-ar、nmvs gcc-nm）是否重要？
gcc-ar是 GNU 的包装器，ar例如一个命令：
gcc-ar ...
相当于：
ar --plugin=/path/to/liblto_plugin.so ...
在我目前的系统上，Ubuntu 17.10，GCC 7.2，例如：
ar --plugin=/usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so
nm和之间的关系是一样的gcc-nm。
--pluginbinutils的选项ar使nm他们能够为他们必须处理的某些非默认格式的目标文件动态加载识别器/分析器。
共享库liblto_plugin.so使他们能够处理链接时间优化构建中生成和使用的 IR（中间表示）对象文件。
因此，如果您要像这样进行简单的旧构建：
$ gcc -c main.c foo.c bar.c
$ ar cr libfoobar.a foo.o bar.o
$ gcc -o prog main.o -L. -lfoobar
然后你会做你的链接时间优化构建，如：
$ gcc -flto -c main.c foo.c bar.c
$ gcc-ar cr libfoobar.a foo.o bar.o
$ gcc -flto -o prog main.o -L. -lfoobar
在最近发布的binutils- 我不知道哪个是第一个；在过去 3 或 4 年内 -liblto_plugin.so默认情况下已由ar
and加载nm；所以事实上：
$ gcc -flto -c main.c foo.c bar.c
$ ar cr libfoobar.a foo.o bar.o
$ gcc -flto -o prog main.o -L. -lfoobar
会正常工作；并且nm foo.o会正常工作。但是这些gcc-*版本仍然具有与 GCC 一起独立发布的目的，因为您的常规版本ar可能nm不支持该默认值，如果不支持，那么最后一个版本将在与未定义引用的链接中失败，因为ar将无法插入存档foo.o和的真实符号表bar.o。