为什么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/

为什么在我在LIBRARY_PATH变量中明确指定之前,g ++会查看这些替代方案以及一大堆其他系统位置,以及这在哪里记录？

我会理解是否在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 ++搜索/lib/../lib/,然后是/ 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.组织/ onlinedocs/GCC-4.7.1/GCC /环境-Variables.html#环境的变量

据我所知,如果不编译自己的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.  */

然而,评论后面的功能不是很明显.

Answer 2

这是multilib工作 - 一种机制,允许在一台机器上拥有多个体系结构的库(以及整个编译和构建工具链).这个Wiki声明"multilib后缀被附加到GCC搜索库的所有目录,并通过-L选项传递给链接器.链接器本身没有任何关于multilibs的特定知识,并将继续查询其默认搜索目录在-L路径中找不到库.如果在单个编译中使用多个正交ABI更改选项,则可以串联使用多个multilib后缀."

因此,根据以上描述,架构标记串或其不同变体被附加到编译器接收的每个库搜索路径,因为它不区分默认路径和自定义路径.您的自定义路径是行中的第一个,但它经历与其他路径相同的"扩展"过程.

由于需要处理i386兼容性,现在似乎默认在大多数x64发行版上使用multilib机制,这在实践中意味着大多数安装.

Answer 3

看起来需要交叉编译。从变更日志：

  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);
      }