Как открыть файлы из приложения NaCl Dev Environment?

Question

Я пытаюсь получить простое приложение командной строки для запуска в 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$ 

Это явно возможно приложение для открытия файлов в произвольных местах в среде Dev - Я используя nano для редактирования тестового кода! Но версия naclports nano doesn't look like it's been changed способами, которые немедленно связаны с манипулированием файлами ..?

Lua - другое приложение, которое appears to have only been modified very slightly. Он падает где-то посередине, поскольку он может запускать тестовые файлы, но только если они помещены в /mnt/html5 и не будут загружать их из домашней папки. Моя тестовая программа не показывает разницы в поведении, если я ее поменю, чтобы посмотреть в /mnt/html5.

NB. моя цель здесь - создать терминальное приложение, которое я могу использовать в среде dev вместе с Lua и nano и т. д., а не с браузером - я предполагаю, что имеет значение для правил обработки файлов.

Answer 1

программы выполняются в NaCl Dev окружающей среды в настоящее время необходимо связана с -lcli_main (который, в свою очередь, зависит от -lnacl_spawn) точки входа, который понимает, как взаимодействовать с JavaScript «ядра» в naclprocess.js. Они нуждаются в этом, чтобы узнать, из какой текущей рабочей директории они были запущены, а также узнать о смонтированных файловых системах.

Программы, связанные с просто ppapi_simple, могут быть запущены, но не будут настраивать все точки монтирования, которые может ожидать среда-разработчик.

В dev env есть скрипт-компоновщик, который упрощает связывание командной строки -lmingn.Например, тестовая программа от вопроса может быть скомпилирован с:

gcc test.c -o test -lmingn

Примечание: Этот линкер сценарий был недавно решен вопрос, новая версия с исправлением был опубликован в магазин на 5/5/2015 ,

В ближайшем будущем мы планируем упростить ситуацию, разрешив main быть точкой входа.

Спасибо за указание, что в порту lua отсутствует новая точка входа! Я зарегистрировал проблему и буду изучать ее в ближайшее время: https://code.google.com/p/naclports/issues/detail?id=215

Answer 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 

... то он будет работать, как ожидалось, и записать файл.

Вместо регистрации наших собственных not- main функции с PPAPI_SIMPLE_REGISTER_MAIN, втягивая cli_main заставляет его делать это с внутренней функцией, которая устанавливает некоторые вещи, предположительно, в том числе и то, что нужно для записи файла, чтобы работать, и ожидает, что тогда способный вызвать nacl_main, который оставлен программе для определения с внешней видимостью (несколько слоев поддельной - main укладка продолжается). Вот почему изменения в нано выглядят настолько минимальными.

nacl_spawn необходимо связать потому, что cli_main использует его для ... чего-то.