我的LIBRARY_PATH环境variables中有一个自定义目录： /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/
为什么在我在LIBRARY_PATHvariables中明确指定之前 ，g ++会查找这些替代方法和一大堆其他系统位置，并在何处logging这些信息？
我会理解，如果在LIBRARY_PATH和LIBRARY_PATH /../ lib64等之前search到系统默认值，但是g ++将LIBRARY_PATH /../ lib64，然后是系统path，然后是LIBRARY_PATH。 这个订单在哪里logging？
我的g ++版本是g++ (SUSE Linux) 4.6.2
我的操作系统是openSUSE 12.1 (x86_64)
在这里问了一个类似的问题： g ++搜索/lib/../lib/，然后/ lib /
这些令人恐惧的搜索路径至少部分是由编译器本身构建时确定的，例如在配置阶段。 很显然，它超越了环境变量，因为可能安装了多个GCC副本，并且每个副本都为gcc --print-search-dirs提供了不同的结果。 同时注意到g++ --print-search-dirs和gcc --print-search-dirs给出了不同的结果，g ++ wrapper也影响了搜索路径。 除了配置/编译时间差异之外，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选项指定你的自定义库。 我之所以这样说，是因为在例如LIBRARY_PATH之前搜索了-L（参见上面关于环境变量的链接）。 为了使它更容易，你可以在你的.bashrc文件中为g ++添加一个别名，包括-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. */
然而，评论之后的功能不是很明显。
这是在工作multilib – 一种机制，允许在一台机器上有多个体系结构的库（但也包括整个编译和构建工具链）。 这个Wiki指出：“multilib后缀被附加到GCC搜索库的所有目录中，并通过-L选项传递给链接器。链接器本身没有任何关于multilib的特殊知识，并且将继续查询它的默认搜索目录if在-L路径中找不到一个库，如果在一个编译中使用了多个正交ABI改变选项，则可以使用多个multilib后缀串联。
因此，根据以上描述，由于体系结构标记字符串或其不同的变体被附加到编译器接收的每个库搜索路径，因为它不区分默认路径和定制路径。 您的自定义路径首先在行中，但是与其他路径经历相同的“扩展”过程。
由于需要处理i386的兼容性，multilib机制现在似乎在大多数x64发行版上默认使用，实际上这意味着大部分安装在那里。
我有完全相同的问题：
Fedora 17, gcc 4.7 and gcc 4.3 CentOS 6.3, gcc 4.4 Unubuntu 12, gcc 4.6
所以看起来这是大多数gcc版本的问题。 可能这个奇怪的行为首先出现在gcc 4.2中，至少按照这个 。
我试图复制规格，并与他们玩。 它看起来像*multilib规范是用来追加特定的字符串取决于平台。 例如我的原始空间看起来像：
*multilib: . !m64 !m32;64:../lib64 m64 !m32;32:../lib !m64 m32;
当我将64:../lib64更改为64:../lib而不是../lib64 gcc追加../lib 。 但是我不能完全解读*multilib或其他任何规格的含义。
看起来这是交叉编译所需要的。 从ChangeLog：
Wed Mar 29 14:53:23 1995 Jim Wilson <wilson@cygnus.com> * gcc.c (process_command): Delete code modifying gcc_exec_prefix. (main): Put it here after last use of gcc_exec_prefix. For cross compiler, set startfile_prefixes if gcc_exec_prefix is set and standard_startfile_prefix is a relative path.
startfile_prefixes是使用search-dirs标志打印的内容。 从gcc/gcc.c ：
if (print_search_dirs) { printf (_("install: %s%s\n"), standard_exec_prefix, machine_suffix); printf (_("programs: %s\n"), build_search_list (&exec_prefixes, "", 0)); printf (_("libraries: %s\n"), build_search_list (&startfile_prefixes, "", 0)); return (0); }
编译器将首先查看其他路径的默认路径。 当你打印的时候，它是如何排序的，现在我不这么做了，但是这里有记录， 3.19影响GCC的环境变量 。
路径由内置规格定义。 规范定义了流水线如何处理源代码以获得结果。 GCC只是驱动编译。
你可以通过-spec=给GCC你自己的spec文件，你可以用-dumpspecs IIRC获得内建的spec。
这可能是在GCC手册的某处解释的。