Skip to content

About building and shipping the IRT #25

Description

@illwieckz

It would be nice if we can keep the ability to build the IRT files.

Though, this is low priority. What matters it to be able to rebuild the code that runs outside the sandbox (the loader, the loader bootstrap, the compiler…).

When symlinking the prebuilt toolchains directory from a depot-managed google native_client upstream, we can build the IRT files from the sources in this repository:

ln -s .../depot/native_client/toolchain
scons platform=x86-64 naclsdk_validate=0 sysinfo=0 -j8 irt_core
scons platform=x86-32 naclsdk_validate=0 sysinfo=0 -j8 irt_core
scons platform=arm naclsdk_validate=0 sysinfo=0 -j8 irt_core

Those files are then produced:

scons-out/nacl_irt-x86-64/staging/irt_core.nexe
scons-out/nacl_irt-x86-32/staging/irt_core.nexe
scons-out/nacl_irt-arm/staging/irt_core.nexe

Even if one day we get Saigo build the IRT, it would be annoying to build the IRT with the loader.

For example, when building the linux-armhf external_deps on linux-amd64, we would need:

  • saigo linux-armhf to package it
  • saigo linux-amd64 to build the IRT
  • gcc linux-amd64 to build the loader

It's better to ship the irt nexe as is. We may even just store them in the repository.

Either we store the IRT files in repository, either we store them as a release downloadable file on GitHub.

If we store the IRT in repository, it makes it easy to package the IRT file with the loader.

If we store the IRT in as a release downloadable file, one not rebuilding the loader would download the loader tarball and the IRT tarball separately.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions