为什么g ++看起来在LIBRARY_PATH /../ lib64和这是记录在哪里？ [英] Why does g++ look in LIBRARY_PATH/../lib64 and where is this documented?

问题描述

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

My LIBRARY_PATH environment variable has a custom directory in it: /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_PATH 变量中明确指定的之前，g ++会查看这些选项和一系列其他系统位置，

Why does g++ look in these alternatives and a whole bunch of other system locations before what I explicitly specify in the LIBRARY_PATH variable, and where is this documented?

我会理解，如果在LIBRARY_PATH和LIBRARY_PATH /../ lib64等之前搜索系统默认值，但是g ++将LIBRARY_PATH /../ lib64 ，然后是系统路径，然后是LIBRARY_PATH。

I would understand if system defaults were searched before LIBRARY_PATH and LIBRARY_PATH/../lib64, etc, but g++ puts LIBRARY_PATH/../lib64, then system paths, then LIBRARY_PATH. Where is this ordering documented?

我的g ++版本是 g ++（SUSE Linux）4.6.2

我的操作系统是 openSUSE 12.1（x86_64）

推荐答案

这里提出了一个类似的问题：
g ++搜索/lib/../lib/,/ lib /

A similar question was asked here: 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

These scary-looking search paths are determined at least in part when the compiler itself it built, for example during the configure phase. It's clear that it goes beyond environment variables because it's possible to have multiple copies of GCC installed and have each of them give different results for gcc --print-search-dirs. Also noting that g++ --print-search-dirs and gcc --print-search-dirs give different results points out that the g++ wrapper is also affecting the search path. Besides configure/build time differences, GCC is definitely aware of the path where its own executable is, and will search subdirectories of that path. A lot of this alchemy can be found in the GCC documentation:
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（请参阅上面的环境变量链接）。为了使它更容忍，你可以在.bashrc文件中为g ++添加一个别名，包括-L选项。

As far as I know, the most forceful thing that you can without compiling your own copy of GCC is to specify your custom libraries using the -L option. The reason I say this is because -L is searched before e.g. LIBRARY_PATH (see the above link on environment variables). In order to make it more tolerable you could add an alias for g++ including the -L option in your .bashrc file.

如果你想要一个确定的答案，的GCC源代码是一种方式。例如，在gcc.c中出现以下高度暗示性的注释：

If you want a definitive answer then downloading a copy of the GCC source code is one way. For example, in gcc.c the following highly suggestive comment appears:

/* 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.  */

但是注释后的函数不是很明显。

However the function that follows the comment is not very obvious.

这篇关于为什么g ++看起来在LIBRARY_PATH /../ lib64和这是记录在哪里？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！