c++ - 为什么 g++ 在 LIBRARY_PATH/../lib64 中查找，这在哪里记录？

Question

我的 LIBRARY_PATH 环境变量中有一个自定义目录:/cs/public/lib/pkg/opencv/lib。

但是，当我使用 g++ --print-search-dirs 时，我得到了这个:

libraries: =
/cs/public/lib/pkg/opencv/lib/x86_64-suse-linux/4.6/:
/cs/public/lib/pkg/opencv/lib/../lib64/:
/usr/lib64/gcc/x86_64-suse-linux/4.6/:
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/lib/x86_64-suse-linux/4.6/:
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/lib/../lib64/:
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../x86_64-suse-linux/4.6/:
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64/:
/lib/x86_64-suse-linux/4.6/:
/lib/../lib64/:
/usr/lib/x86_64-suse-linux/4.6/:
/usr/lib/../lib64/:
/cs/public/lib/pkg/opencv/lib/:
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/lib/:
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../:
/lib/:
/usr/lib/

为什么 g++ 会在这些替代方案和一大堆其他系统位置之前查看我在 LIBRARY_PATH 变量中明确指定的内容，并且记录在哪里？ p>

如果在 LIBRARY_PATH 和 LIBRARY_PATH/../lib64 等之前搜索系统默认值，我会理解，但是 g++ 会先放置 LIBRARY_PATH/../lib64，然后是系统路径，然后是 LIBRARY_PATH。此订购记录在哪里？

我的 g++ 版本是 g++ (SUSE Linux) 4.6.2

我的操作系统是 openSUSE 12.1 (x86_64)

Answer 1

这里问了一个类似的问题: g++ searches /lib/../lib/, then /lib/

这些看起来很吓人的搜索路径至少部分是在它构建的编译器本身时确定的，例如在配置阶段。很明显，它超越了环境变量，因为可以安装多个 GCC 拷贝，并让每个拷贝为 gcc --print-search-dirs 提供不同的结果。还要注意 g++ --print-search-dirs 和 gcc --print-search-dirs 给出不同的结果指出 g++ 包装器也在影响搜索路径。除了配置/构建时间差异之外，GCC 肯定知道它自己的可执行文件所在的路径，并将搜索该路径的子目录。在 GCC 文档中可以找到很多这种炼金术:
http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Directory-Options.html#Directory-Options
http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Environment-Variables.html#Environment-Variables

据我所知，在不编译自己的 GCC 拷贝的情况下，最有力的方法是使用 -L 选项指定自定义库。我这么说的原因是因为 -L 在例如之前被搜索过。 LIBRARY_PATH(请参阅上面有关环境变量的链接)。为了让它更容易忍受，你可以为 g++ 添加一个别名，包括在你的 .bashrc 文件中的 -L 选项。

如果您想要一个明确的答案，那么下载 GCC 源代码的拷贝是一种方法。例如，在 gcc.c 中会出现以下高度暗示性的注释:

/* Build a list of search directories from PATHS.
   PREFIX is a string to prepend to the list.
   If CHECK_DIR_P is true we ensure the directory exists.
   If DO_MULTI is true, multilib paths are output first, then
   non-multilib paths.
   This is used mostly by putenv_from_prefixes so we use `collect_obstack'.
   It is also used by the --print-search-dirs flag.  */

不过注释后面的功能不是很明显。