Очень простые вопросы о google-nacl

Question

Правильно ли, что от перца 18 лет мне не нужна система сборки scons для компиляции, а скорее использовать gcc (nacl-versions) и make-файлы?

Также верно ли, что сгенерированные файлы .nexe будут работать на любом веб-сервере платформ, а не только на платформе, на которой она была скомпилирована? Так, например, модуль внутреннего кода разработан и скомпилирован под Mac OS, а также генерирует 32-битный и 64-разрядный файлы nexe. Веб-сервер я загружу этот модуль при запуске на Linux, и все равно будет выполнять модули как в 32-битной, так и в 64-битной версиях?

Answer 1

система сборки для Native Client

Нет версии Native Client SDK мандатами конкретной системы сборки; в любой момент было возможно использовать SCons, GNU Make, CMake или даже скрипты оболочки. Иными словами, компиляторы и инструменты, основанные на gcc и программной цепочке GNU, не зависят от системы сборки, которую разработчик решает использовать.

Однако, вплоть до версии Pepper версии 17 SDK собственного клиента, в примерах в SDK появились файлы сборки для SCons, а SCons был включен в SDK. От Pepper 18 и далее это уже не так. Вместо этого файлы сборки, представленные для примеров, являются Make-файлами, предназначенными для GNU Make.

Также см. release notes для версии SDK Pepper 18.

кросс-компиляции

средства, предоставляемые в SDK в настоящее время поддерживает 32-битную x86 и 64-разрядных x86 архитектур. Платформа веб-сервера не важна, потому что модуль Native Client работает на клиенте (то есть в браузере). Это означает, что есть две системы: система пользователя и система разработчика.

В системе пользователя, когда Chrome обнаруживает собственный клиентский модуль на странице, он извлекает исполняемый файл (.nexe), который подходит для браузера на этом клиенте. Следовательно, если пользователь на 64-битной Windows посещает страницу, будет извлечен 64-битный двоичный код; если пользователь находится на 32-разрядном Mac, вызывается 32-битный двоичный файл. Существуют исключения, которые я буду рассматривать отдельно ниже. Chrome определяет имена 32-разрядных и 64-разрядных .nexes из файла манифеста. См. Сайт SDK собственного клиента (www.GoNaCl.com) по адресу: a description and an example of a manifest file

Разработчик может - и должен - производить как 32-разрядные, так и 64-разрядные исполняемые файлы независимо от операционной системы и архитектуры, используемой для разработки. Запуск «make» в каталоге examples/Pepper 18 и просмотр выданных команд - удобный способ увидеть, как это сделать. Например, часть продукции 'сделать hello_world_glibc' читает что-то вроде:

i686-nacl-gcc -o hello_world_x86_32.nexe hello_world.c -m32 -O0 -g -pthread -O0 -g -Wno-long-long -Wall -lppapi 

и

i686-nacl-gcc -o hello_world_x86_64.nexe hello_world.c -m64 -O0 -g -pthread -O0 -g -Wno-long-long -Wall -lppapi 

Первая линия производит 32-битный .nexe; вторая строка - 64-разрядный .nexe. Важным флагом является -m32/-m64, который определяет архитектуру - всегда создавайте оба, так что клиент на обеих 32-битных и 64-битных машинах может использовать приложение.

Долгий срок, потребуется только один формат развертывания, а ARM будет добавлен в качестве архитектуры, поддерживаемой напрямую. Подробнее см. Проект Portable Native Client.

Вот специфическое совпадение браузера и архитектуры клиент 32/64 бит:

• Mac OS (32-разрядная и 64-разрядная версия) -> 32-битный .nexe (Хром 32-разрядный)
• для Windows (32-битный) -> 32-битный .nexe
• Windows (64-бит) -> 64-битной .nexe (Хром 32-битный, но начинает процесс брокера 64-битный)
• Linux (32-разрядный) -> 32-разрядный .nexe
• Linux (64-разрядный) -> 32-разрядный хеш-выбор из 32-разрядного .nexe; 64-битный Chrome получает 64-битный .nexe

Так как общее правило Chrome извлекает .nexe, что соответствует его собственному битовому возрасту - за исключением 64-битных Windows, где Chrome выбирает 64-разрядные .nexe несмотря будучи самой 32-битной.