illumos build should support alternate adjuncts
Currently, illumos is not self-contained; its build encoded runtime dependencies based on a number of objects found on the build machine outside its source tree. These include python, libxml2, libexpat, and a number of other headers and libraries. This is hazardous to build reproducibility, makes it impossible to cross-compile, and imposes unnecessary requirements on build system configuration.
While the correct solution is to incorporate all required objects into illumos and/or remove dependents until the entire gate is fully self-contained, a useful interim step is also possible. The build system should support an alternate adjuncts path in which these non-illumos objects may be found. This enables distributors to ensure that illumos is built against the same set of non-illumos objects that will ultimately be delivered to customers, and to create fully bootstrapped builds. Very similar work was previously done by Adam Leventhal at Fishworks to support dependencies on non-ON objects delivered by other consolidations via IPS packages; the approach proved highly effective.
This change proposes that the make/environment variable ADJUNCT_PROTO point to the root of an additional proto area in which non-illumos dependencies may be located. The default value will be empty, resulting in the same behavior that exists today. All flags incorporating dependencies on objects outside the illumos proto area itself will be modified to explicitly include $(ADJUNCT_PROTO), with of course the exception of the link-editor's -R flag. The result will be that all type, structure, symbol, and versioning data for runtime dependencies will come from a single controlled location rather than the objects installed on the build system.
Similarly, a NATIVE_ADJUNCT variable will be introduced such that tools build and executed on the build system itself may locate dependencies outside /usr if needed. This is mainly useful in environments such as SmartOS that deliberately isolate customer-usable environments from the illumos versions of third-party software such as OpenSSL and zlib by not delivering headers and compilation symlinks. In such environments, alternate canonical versions of this software are available for installation and use by the build system, but are found in alternate locations. This may also be useful for testing the impact of changes to these build-time dependencies on the illumos build process without affecting other users of the system.