Gcc 链接器在运行Bazel时在沙盒中失败，但在从命令行执行沙盒命令时工作

我试图让我们的交叉工具链（标准Yocto工具链）与Bazel一起工作。我按照上的说明进行操作，但每次尝试构建一个简单的测试程序时，链接器都会失败。上面说

external/toolchain_e6500/sysroots/x86_64-fslsdk-linux/usr/bin/powerpc64-fsl-linux/../../libexec/powerpc64-fsl-linux/gcc/powerpc64-fsl-linux/4.9.2/real-ld: cannot find /lib64/libc.so.6
external/toolchain_e6500/sysroots/x86_64-fslsdk-linux/usr/bin/powerpc64-fsl-linux/../../libexec/powerpc64-fsl-linux/gcc/powerpc64-fsl-linux/4.9.2/real-ld: cannot find /usr/lib64/libc_nonshared.a
external/toolchain_e6500/sysroots/x86_64-fslsdk-linux/usr/bin/powerpc64-fsl-linux/../../libexec/powerpc64-fsl-linux/gcc/powerpc64-fsl-linux/4.9.2/real-ld: cannot find /lib64/ld64.so.1

系统根已正确设置。在沙箱外部运行链接器命令时（例如，使用

--spawn_strategy=standalone

或仅手动），链接器命令始终有效。奇怪的是，当我使用

--debug_sandbox

并从命令行运行发出的命令时，它也能工作

我已经调试这个问题两天了，包括

strace

ing Bazel守护进程和比较

real ld

输入，但我没有发现任何可疑的东西

执行环境之间一定有区别，但我现在没有主意了。下面是由

--debug\u sandbox

打印的失败命令：

(cd /home/sick/.cache/bazel/_bazel_sick/2a7ae5e27644389520091aa03d045c73/execroot/__main__ && \
  exec env - \
    PATH=/home/sick/bin:/home/sick/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/sick/bin \
    PWD=/proc/self/cwd \
    TMPDIR=/tmp \
  /home/sick/.cache/bazel/_bazel_sick/2a7ae5e27644389520091aa03d045c73/execroot/__main__/_bin/linux-sandbox -t 15 -w /home/sick/.cache/bazel/_bazel_sick/2a7ae5e27644389520091aa03d045c73/sandbox/linux-sandbox/2/execroot/__main__ -w /tmp -w /dev/shm -D -- tools/compiler_e6500/e6500_gcc/powerpc64-fsl-linux-gcc -o bazel-out/e6500-fastbuild/bin/test '--sysroot=external/toolchain_e6500/sysroots/ppc64e6500-fsl-linux' -no-canonical-prefixes -pie -Wl,-z,relro,-z,now -Wl,-S -Wl,@bazel-out/e6500-fastbuild/bin/test-2.params)

您可以在这里查看工作区

如果需要，我可以提供工具链

---

更新2018-09-25

在阅读了下面关于链接器脚本的答案后，我做了更多的调查。中的第4.4.2节指出

如果配置了sysroot前缀，文件名以 字符和正在处理的脚本位于 sysroot前缀，将在sysroot前缀中查找文件名。 否则，链接器将尝试在当前文件夹中打开该文件 目录

显然，

ld

不会将脚本视为位于sysroot前缀内，因此不会直接使用（即相对于当前目录解析，可能是沙盒根）。这可以解释观察到的行为。但是，我仍然不明白为什么在手动运行命令时（即不是通过Bazel守护进程）不会发生这种情况

---

这是否与

CROSSTOOL

文件中使用的相对系统根路径有关？据我所知，由于沙箱的原因，您无法指定sysroot的绝对路径。在Bazel中处理此问题的推荐方法是什么？我希望避免修补工具链。

看看sysroot中的

lib.so

。它可能看起来像这样：

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/x86_64-linux-gnu/libc_nonshared.a  AS_NEEDED ( /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 )

将其中的路径更改为相对于

libc.所在的目录。您必须在
libm.so
和
libpthread.so
上执行类似的操作

GNU链接器在评估脚本是否在sysroot中之前解析符号链接。当前的Bazel Linux沙盒实现将所有操作的输入都创建一个符号链接场。因此，
libc.so.6
链接器脚本被检测到位于沙盒外部的sysroot中，但不在沙盒中。
您是对的，在创建这些相对路径后，链接器成功。但是相对于配置的sysroot，这些路径不应该由ld解析吗？在沙盒环境之外，这很好，所以系统根似乎被考虑在内。请参阅我的编辑。区别在于，一切都是沙盒中的符号链接。