如何从 NaCl 开发环境应用程序打开文件？答案

【问题标题】：How to open files from a NaCl Dev Environment application?如何从 NaCl 开发环境应用程序打开文件？
【发布时间】：2015-05-05 00:59:08
【问题描述】：

我正在尝试让一个简单的命令行应用程序在NaCl Development Environment 中运行。但我不明白为什么它不想打开文件：

#include <stdio.h>
#include <ppapi_simple/ps_main.h>
int my_main (int argc, char ** argv) {
  FILE * f = fopen ("out.txt","w");
  if (f) {
    fputs ("output to the file", f);
    fclose(f);
  } else {
    puts("could not open file");
  }
}
PPAPI_SIMPLE_REGISTER_MAIN(my_main)

跑步：

bash.nmf-4.3$ gcc -I"$NACL_SDK_ROOT/include" test.c -lppapi_simple -lnacl_io -lppapi
bash.nmf-4.3$ ./a.out 
could not open file
bash.nmf-4.3$

应用程序显然可以在开发环境中的任意位置打开文件 - 我正在使用 nano 来编辑测试代码！但是 naclports 版本的 nano doesn't look like it's been changed 以直接连接到文件操作的方式..？

Lua 是 appears to have only been modified very slightly 的另一个应用程序。它介于两者之间，因为它可以运行测试文件，但前提是它们位于/mnt/html5 中，并且不会从主文件夹加载它们。如果我将其更改为查看/mnt/html5，我的测试程序在行为上没有任何差异。

注意。我的目标是构建一个终端应用程序，我可以在开发环境中与 Lua 和 nano 等一起使用，而不是基于浏览器的应用程序 - 我认为这会对文件处理规则产生一些影响。

【问题讨论】：

标签： c google-chrome file-io google-nativeclient

【解决方案1】：

在 NaCl 开发环境中运行的程序目前需要与-lcli_main（这又依赖于-lnacl_spawn）链接，以获得一个了解如何与naclprocess.js 中的javascript“内核”通信的入口点。他们需要这个来知道他们从哪个当前工作目录运行，以及听说挂载的文件系统。

可以运行仅与 ppapi_simple 链接的程序，但不会设置开发环境可能期望的所有挂载点。

在开发环境中有一个链接器脚本可以简化链接命令行程序-lmingn。例如，问题中的测试程序可以编译为：

gcc test.c -o test -lmingn

注意：此链接器脚本最近解决了一个问题，带有该修复程序的新版本已于 2015 年 5 月 5 日发布到商店。

在不久的将来，我们计划通过允许main 作为入口点来进一步简化事情。

感谢您指出 lua 端口缺少新的入口点！我已经提交了一个问题，并将尽快修复它： https://code.google.com/p/naclports/issues/detail?id=215

【讨论】：

【解决方案2】：

我找到了一个解决方案，虽然我不完全理解它在做什么。事实证明，对 nano 所做的微小更改很重要，因为它们会导致 NaCl 库中其他地方的一些其他函数被拉入，从而正确设置文件处理环境。

如果上面的文件改成：

#include <stdio.h>
int nacl_main (int argc, char ** argv) {
  FILE * f = fopen ("out.txt","w");
  if (f) {
    fputs ("output to the file", f);
    fclose(f);
  } else {
    puts("could not open file");
  }
}

...并用另外两个库编译：

gcc -I"$NACL_SDK_ROOT/include" test.c -lppapi_simple -lnacl_io -lppapi -lcli_main -lnacl_spawn

...然后它将按预期工作并写入文件。

不是用PPAPI_SIMPLE_REGISTER_MAIN 注册我们自己的not-main 函数，而是拉入cli_main 使它使用一个内部函数来设置一些东西，大概包括文件写入工作所需的东西，并期望随后能够调用nacl_main，这留给程序定义外部可见性（几层fake-main堆叠正在进行）。这就是为什么 nano 的变化看起来如此微小的原因。

nacl_spawn 需要关联，因为cli_main 将其用于...某事。

【讨论】：