g++ 搜索 /lib/../lib/,然后搜索 /lib/

发布于 2024-07-24 04:49:45 字数 773 浏览 7 评论 0 原文

根据 g++ -print-search-dirs 我的 C++ 编译器正在许多目录中搜索库,包括 ...

  • /lib/../lib/:
  • /usr/lib/../lib/ :
  • /lib/:
  • /usr/lib/

天真地,/lib/../lib/ 看起来与 /lib/ 相同的目录 - lib 的父目录将具有一个名叫 lib 的孩子,“那个人的父亲的儿子是我父亲的儿子的儿子”等等。 对于 /usr/lib/../lib//usr/lib/ 也是如此

  1. 是否有某种原因,可能与符号链接有关, g++ 应该配置为搜索 /lib/../lib//lib/

  2. 如果这是不必要的冗余,那么如何解决它?

如果重要的话,这是在未修改的 Ubuntu 9.04 安装上观察到的。

编辑:更多信息。

结果是从 bash shell 执行 g++ -print-search-dirs 而不使用其他开关。

printenv 不会输出 LIBRARY_PATH 和 LPATH,并且 echo $LPATHecho LIBRARY_PATH 都返回空行。

According to g++ -print-search-dirs my C++ compiler is searching for libraries in many directories, including ...

  • /lib/../lib/:
  • /usr/lib/../lib/:
  • /lib/:
  • /usr/lib/

Naively, /lib/../lib/ would appear to be the same directory as /lib/ — lib's parent will have a child named lib, "that man's father's son is my father's son's son" and all that. The same holds for /usr/lib/../lib/ and /usr/lib/

  1. Is there some reason, perhaps having to do with symbolic links, that g++ ought to be configured to search both /lib/../lib/ and /lib/?

  2. If this is unnecessary redundancy, how would one go about fixing it?

If it matters, this was observed on an unmodified install of Ubuntu 9.04.

Edit: More information.

The results are from executing g++ -print-search-dirs with no other switches, from a bash shell.

Neither LIBRARY_PATH nor LPATH are output from printenv, and both echo $LPATH and echo LIBRARY_PATH return blank lines.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

诗酒趁年少 2024-07-31 04:49:46

尝试寻找答案(这是我通过几分钟查看 gcc.c 驱动程序源代码和 Makefile 环境而收集到的)。

这些路径是在运行时从以下位置构建的:

  1. GCC exec 前缀(请参阅 GCC_EXEC_PREFIX 的 >GCC 文档
  2. $LIBRARY_PATH 环境变量
  3. $LPATH 环境变量(被视为 $ LIBRARY_PATH)
  4. 传递给 -B 命令行开关的任何值
  5. 标准可执行文件前缀(在编译时指定)
  6. Tooldir 前缀

最后一个(tooldir 前缀)通常定义为相对路径:
来自 gcc 的 Makefile.in

# Directory in which the compiler finds libraries etc.
libsubdir = $(libdir)/gcc/$(target_noncanonical)/$(version)
# Directory in which the compiler finds executables
libexecsubdir = $(libexecdir)/gcc/$(target_noncanonical)/$(version)
# Used to produce a relative $(gcc_tooldir) in gcc.o
unlibsubdir = ../../..
....
# These go as compilation flags, so they define the tooldir base prefix
# as ../../../../, and the one of the library search prefixes as ../../../
# These get PREFIX appended, and then machine for which gcc is built
# i.e i484-linux-gnu, to get something like: 
# /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../i486-linux-gnu/lib/../lib/
DRIVER_DEFINES = \
-DSTANDARD_STARTFILE_PREFIX=\"$(unlibsubdir)/\" \
-DTOOLDIR_BASE_PREFIX=\"$(unlibsubdir)/../\" \

但是,这些是针对编译器版本特定的路径。 您的示例可能受到我上面列出的环境变量的影响(LIBRARY_PATHLPATH

An attempt at an answer (which I gathered from a few minutes of looking at the gcc.c driver source and the Makefile environment).

These paths are constructed in runtime from:

  1. GCC exec prefix (see GCC documentation on GCC_EXEC_PREFIX)
  2. The $LIBRARY_PATH environment variable
  3. The $LPATH environment variable (which is treated like $LIBRARY_PATH)
  4. Any values passed to -B command-line switch
  5. Standard executable prefixes (as specified during compilation time)
  6. Tooldir prefix

The last one (tooldir prefix) is usually defined to be a relative path:
From gcc's Makefile.in

# Directory in which the compiler finds libraries etc.
libsubdir = $(libdir)/gcc/$(target_noncanonical)/$(version)
# Directory in which the compiler finds executables
libexecsubdir = $(libexecdir)/gcc/$(target_noncanonical)/$(version)
# Used to produce a relative $(gcc_tooldir) in gcc.o
unlibsubdir = ../../..
....
# These go as compilation flags, so they define the tooldir base prefix
# as ../../../../, and the one of the library search prefixes as ../../../
# These get PREFIX appended, and then machine for which gcc is built
# i.e i484-linux-gnu, to get something like: 
# /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../i486-linux-gnu/lib/../lib/
DRIVER_DEFINES = \
-DSTANDARD_STARTFILE_PREFIX=\"$(unlibsubdir)/\" \
-DTOOLDIR_BASE_PREFIX=\"$(unlibsubdir)/../\" \

However, these are for compiler-version specific paths. Your examples are likely affected by the environment variables that I've listed above (LIBRARY_PATH, LPATH)

几度春秋 2024-07-31 04:49:46

好吧,理论上,如果 /lib 是 /drive2/foo 的符号链接,那么如果我没记错的话 /lib/../lib 将指向 /drive2/lib 。 理论上...

编辑:我刚刚测试过,但事实并非如此 - 它返回到/lib。 嗯:(

Well, theoretically, if /lib was a symlink to /drive2/foo, then /lib/../lib would point to /drive2/lib if I'm not mistaken. Theoretically...

Edit: I just tested and it's not the case - it comes back to /lib. Hrm :(

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文