efs mount 使 arm-linux-gnueabihf-gcc CC 丢失其组件路径

Question

我一直在尝试让我的 CC 工具链安装在 EFS 上，以便我的 jenkins slaves 可以使用它们。我注意到的是，无论我如何将工具链放在 EFS 上（直接 cp，直接解压缩），它总是会丢失其组件路径例如

/efs/mount/path/arm-linux-gnueabihf-gcc -print-prog-name=cc1

returns

cc1

而不是

/efs/mount/path/cc1path/cc1

如果我在 ebs 上解压文件并执行相同的命令，我会得到

/home/dir/arm-linux-gnueabihf-gcc -print-prog-name=cc1

returns

/home/dir/cc1path/cc1

我找不到保留这些路径的方法，EFS 是怎么回事？我怎样才能实现在 EFS 上保留路径的目标？

更新：

进一步研究后运行 strace 产量： strace /efs/mount/path/arm-linux-gnueabihf-gcc -print-prog-name=cc1

    stat64("/mnt/crosscompilers/altera-linux/linaro/gcc-linaro-arm-linux-gnueabihf-4.7-2012.11-20121123_linux/bin/../libexec/gcc/ld", 0xffc0d148) = -1 ENOENT (No such file or directory)
stat64("/mnt/crosscompilers/altera-linux/linaro/gcc-linaro-arm-linux-gnueabihf-4.7-2012.11-20121123_linux/bin/../libexec/gcc/arm-linux-gnueabihf/ld", 0xffc0d148) = -1 ENOENT (No such file or directory)
stat64("/mnt/crosscompilers/altera-linux/linaro/gcc-linaro-arm-linux-gnueabihf-4.7-2012.11-20121123_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.7.3/../../../../arm-linux-gnueabihf/bin/arm-linux-gnueabihf/4.7.3/ld", 0xffc0d148) = -1 ENOENT (No such file or directory)
stat64("/mnt/crosscompilers/altera-linux/linaro/gcc-linaro-arm-linux-gnueabihf-4.7-2012.11-20121123_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.7.3/../../../../arm-linux-gnueabihf/bin/ld", {st_mode=S_IFREG|0755, st_size=1017424, ...}) = 0
stat64("/mnt/crosscompilers/altera-linux/linaro/gcc-linaro-arm-linux-gnueabihf-4.7-2012.11-20121123_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.7.3/../../../../arm-linux-gnueabihf/bin/arm-linux-gnueabihf/ld", 0xffc0d148) = -1 ENOENT (No such file or directory)
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
write(1, "ld\n", 3ld
)                     = 3
exit_group(0)                           = ?
+++ exited with 0 +++

当工作目录产生这个时：

stat64("/home/ubuntu/altera-linux/linaro/gcc-linaro-arm-linux-gnueabihf-4.7-2012.11-20121123_linux/bin/../libexec/gcc/ld", 0xffbb1de8) = -1 ENOENT (No such file or directory)
stat64("/home/ubuntu/altera-linux/linaro/gcc-linaro-arm-linux-gnueabihf-4.7-2012.11-20121123_linux/bin/../libexec/gcc/arm-linux-gnueabihf/ld", 0xffbb1de8) = -1 ENOENT (No such file or directory)
stat64("/home/ubuntu/altera-linux/linaro/gcc-linaro-arm-linux-gnueabihf-4.7-2012.11-20121123_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.7.3/../../../../arm-linux-gnueabihf/bin/arm-linux-gnueabihf/4.7.3/ld", 0xffbb1de8) = -1 ENOENT (No such file or directory)
stat64("/home/ubuntu/altera-linux/linaro/gcc-linaro-arm-linux-gnueabihf-4.7-2012.11-20121123_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.7.3/../../../../arm-linux-gnueabihf/bin/ld", {st_mode=S_IFREG|0755, st_size=1017424, ...}) = 0
access("/home/ubuntu/altera-linux/linaro/gcc-linaro-arm-linux-gnueabihf-4.7-2012.11-20121123_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.7.3/../../../../arm-linux-gnueabihf/bin/ld", X_OK) = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
write(1, "/home/ubuntu/altera-linux/linaro"..., 171/home/ubuntu/altera-linux/linaro/gcc-linaro-arm-linux-gnueabihf-4.7-2012.11-20121123_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.7.3/../../../../arm-linux-gnueabihf/bin/ld
) = 171
exit_group(0)                           = ?
+++ exited with 0 +++

注意工作输出中的 'access' 行。实际运行的函数 print_prog_name 是 here。它说

if (stat (temp, &st) >= 0
    && ! S_ISDIR (st.st_mode)
    && access (temp, mode) == 0)
  return temp;

但是从 stat 的输出可以看出，该文件不是目录。并且这两个文件都存在。

Answer 1

TL；DR；

EFS 使用 64 位索引节点，如果没有内核引导参数的帮助，32 位二进制文件无法理解。在我们的例子中更新 /etc/default/grub 为 GRUB_CMDLINE_LINUX="nfs.enable_ino64=0".

回答；

经过一些挖掘，我们发现这是由于 EFS 返回了一个非常大的 inode，导致我们的 32 位二进制文件无法正确读取。内核可以拦截 nfs 请求并调整它们，以便 32 位二进制文件可以通过在 /etc/default/grub 中设置 GRUB_CMDLINE_LINUX="nfs.enable_ino64=0" 并重新启动来理解 64 位 inode。

非常有趣的是，这是我们看到的唯一错误，而且我们的一些二进制文件即使是 32 位的也仍然可以正常运行。我们从来没有弄清楚其中的原因。

efs mount 使 arm-linux-gnueabihf-gcc CC 丢失其组件路径

efs mount makes arm-linux-gnueabihf-gcc CC lose its component paths

cross-compiling

amazon-web-services

amazon-efs