SummaryThis document describes filesystem structure as it is seen by NaCl programs. BackgroundIn Unix world, software often cares about location of installed files and directories. Example: shared libraries should always go to the place where dynamic linker ( ld.so) can find them.Example: default location for iconv data is <glibc-libdir>/gconv.Example: current timezone is set by /etc/localtime.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 ld.so is part of glibc, and it is configured to search for shared libraries under /lib. Thus, libxml should set the runtime path of its shared libraries to be like /lib/libxml.so, otherwise ld.so will not find them.In most cases the install location of packages is specified at configure time with --prefix=<location> configure flag. All that needed is to define the common prefix to be used when compiling all NaCl software.NaCl filesystemDraft version, changes still possible. Be warned! The prefix to configure software for NaCl should be blank. With gnu autotools, run configure like this: configure --prefix= <more-configure-flags>The root filesystem would be: /bin/lib/shareThe reason is to keep names as short as possible while still having canonical filesystem structure. The distinction between / and /usr is considered unessential, thus what usually goes under /usr will go under /.Open question: keep /usr?Do we still want to keep /usr hierarchy?Pros:
Cons:
Open question: use /lib<qual> (/usr/lib<qual>)?/usr/lib<qual> contains libraries in alternate binary format.Example: on x86_64 systems, 64-bit libraries go to /usr/lib, and 32-bit libraries go to /usr/lib32 (or /usr/lib64 and /usr/lib respectively).Pros:
Cons:
Developer handbookHere we discuss how to perform common development tasks with the focus on pathnames tricks.Italic font is for things to be noted by developers of NaCl toolchain and libraries. How do I install the NaCl toolchain?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 /home/<you>/nacl. In the rest of the document, we'll refer this location as NACL_TOOLCHAIN_ROOT.How do I install the dev glibc?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. How do I dynamically link my app with glibc?This should happen by default. How do I run my app with my dev glibc?TODO How do I install more dev libraries?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 How do I deploy my app that uses dynamic libraries?TODO TODO How do I deploy my dynamic library?Filesystem Hierarchy Standard - http://www.pathname.com/fhs/ |
|
Native Client > 5: Design Documents >
Native Client Filesystem Structure |