This document describes filesystem structure as it is seen by NaCl programs.
In Unix world, software often cares about location of installed files and directories.
Example: shared libraries should always go to the place where dynamic linker (
Example: default location for iconv data is
Example: current timezone is set by
To some extend, NaCl can be regarded as a very lightweight variant of Unix.
With static linking only, the locations are not so important as the complete NaCl program is served from a single site and all the issues and collisions are resolved within that single site. However, when NaCl supports dynamic linking, NaCl program will turn into a set of packages served from several distinct sites. At runtime, these packages are combined into a common filesystem, and it is important that they fulfill location expectations of each other within that common filesystem.
Example: NaCl executable from site A uses libxml from site B and glibc from site C. Dynamic loader
In most cases the install location of packages is specified at configure time with
Draft version, changes still possible. Be warned!
The prefix to configure software for NaCl should be blank.
With gnu autotools, run configure like this:
The root filesystem would be:
The reason is to keep names as short as possible while still having canonical filesystem structure. The distinction between
Do we still want to keep
Example: on x86_64 systems, 64-bit libraries go to
Italic font is for things to be noted by developers of NaCl toolchain and libraries.
We should not require NaCl toolchain to go under a specific location.
Properly configured cross tools are relocatable. We do not need to know final install location at configure time.
It should be possible to install NaCl toolchain under any directory of your choice.
For example, you can install the toolchain under
When we configure glibc, we should use --prefix= and then install with install_root=<actual-location>. We can copy glibc to the new location after that, only --prefix is meaningful at runtime (true?).
Glibc comes within the toolchain.
This should happen by default.
TODO: developers may want to install and remove dev libraries at will. Installing libraries inside the toolchain makes the removal almost impossible - can we think how to install dev libraries separately?
TODO: see previous section
Filesystem Hierarchy Standard - http://www.pathname.com/fhs/