如何从NaCl-Dev环境应用程序打开文件？

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

#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)

显然，应用程序可以在开发环境中的任意位置打开文件——我正在使用nano编辑测试代码！但是naclports版本的nano以直接连接到文件操作的方式

Lua是另一个应用程序。它介于两者之间，因为它可以运行测试文件，但前提是这些文件位于

/mnt/html5

中，并且不会从主文件夹加载它们。但是，如果我将测试程序更改为查看

/mnt/html5

，则测试程序的行为没有任何差异

---

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

我找到了解决方案，尽管我不完全了解它在做什么。事实证明，对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");
  }
}

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

与使用

PPAPI\u SIMPLE\u REGISTER\u main

注册我们自己的not-

main

函数不同，拉入

cli\u main

会使它使用一个内部函数进行注册，该函数设置了一些事情，可能包括文件写入工作所需的内容，并期望随后能够调用

nacl\u main

，由程序使用外部可见性进行定义（正在进行几层伪-

main

stacking）。这就是为什么nano的变化看起来如此之小

---

nacl\u-spawn

需要链接，因为

cli\u-main

将其用于…某些事情。

在nacl-Dev环境中运行的程序当前需要链接到

-lcli\u-main

（这反过来取决于

-lnacl\u-spawn

）作为一个入口点，以了解如何与javascript“内核”通信在

naclprocess.js

中。他们需要这些信息来了解运行它们的当前工作目录，以及了解装载的文件系统

仅针对ppapi_simple链接的程序可以运行，但不会设置开发环境可能期望的所有装入点

dev env中有一个链接器脚本，可以简化命令行程序的链接

-lmingn

。例如，问题中的测试程序可以通过以下方式编译：

gcc测试.c-o测试-lmingn

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

在不久的将来，我们计划进一步简化事情，允许

main

作为切入点

感谢您指出lua端口缺少新的入口点！ 我已经提出了一个问题，并将很快着手解决：

#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