Project

General

Profile

Actions

Bug #2927

closed

illumos build should support alternate adjuncts

Added by Keith Wesolowski over 9 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Category:
tools - gate/build tools
Start date:
2012-06-24
Due date:
% Done:

0%

Estimated time:
Difficulty:
Bite-size
Tags:
needs-triage
Gerrit CR:

Description

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.


Related issues

Is duplicate of illumos gate - Feature #3915: Add adjuncts support to the buildResolvedKeith Wesolowski2013-07-28

Actions
Actions #1

Updated by Igor Kozhukhov over 9 years ago

I have a comment:
I thought about it and had idea: configure env with additional userland soft for illumos-gate and use it with 'chroot <dir> nightly illumos.sh'

Idea was in : prepare additional env and provide lofs mount with sources - for emulate root system path.
but we have to understand: we need userland soft for illumos builds and we need illumos provided soft for userland builds. Need identify dependency: what libs/tools should be build before on specific env.

it will be easy if we have the same build env for illumos and userland components, but we have different env.

what we can : we can provide userland components to virtual env without re-builds for illumos builds and use it with 'chroot'

I thought about: build SPARC builds on Intel env after GCC44 integration.
We can prepare cross-compiling toolchain.

No all userland components should be building with another root path when system root "/".
Need pre-build and install dependent package before building final package.
It is argument to my proposal for 'chroot <virtual build env>'.

Actions #2

Updated by Keith Wesolowski over 9 years ago

Igor Kozhukhov wrote:

I have a comment:
I thought about it and had idea: configure env with additional userland soft for illumos-gate and use it with 'chroot <dir> nightly illumos.sh'

There are two components here: the set of software that's executed during the build, and the set of objects used to encode runtime dependencies in the generated illumos deliverables. It's important that we not create circular dependencies between the two. If we assert that both sets of objects always come from /usr (whether on the running system or within a chroot(2) environment), we do exactly that: any library against which we wish to link new software will also, barring a virtually unheard-of major version number bump, will also be used to satisfy relocations within build tools. That's often harmless, but undesirable.

Idea was in : prepare additional env and provide lofs mount with sources - for emulate root system path.
but we have to understand: we need userland soft for illumos builds and we need illumos provided soft for userland builds. Need identify dependency: what libs/tools should be build before on specific env.

This is more or less what smartos-live does today: create a zone, then use lofs mounts to whack in a bunch of crap on top of the software in /usr that represents the running platform. This is several kinds of broken and is something we're actively trying to move away from. The idea is that:

- tools built at compile time and executed on the build system can reference build-system runtime libraries from a defined location or set of locations (NATIVE_ADJUNCT).
- tools that are not built within illumos but are executed during the build may be specified by the various environment/make variables defined in Makefile.master and set via illumos.sh for nightly(1) or bldenv(1). On some systems these may be found in /usr, while on others they may come from pkgsrc or some other source. This mechanism largely exists today, though there are some bugs.
- objects whose properties are actually encoded into the delivered bits (headers and libraries, mainly, but thanks to use of autoconf when building extras in most distributions this is actually undefined) are found in a specified and isolated location other than /usr (ADJUNCT_PROTO).

You are correct that we must identify the dependencies, but that is true regardless of whether one takes the chroot(2) or ADJUNCT_PROTO approach. The next phase of this is to add -YI, (gcc: -nostdinc) and -YP, (gcc: sadly, no real analogue but it accepts the flag and passes it to the linker, which works) in place of -I/-isystem and -L. This will entirely prevent resolution of symbols against the running build system and guarantee that the contents of ADJUNCT_PROTO are complete. This phase is left for a separate bug.

it will be easy if we have the same build env for illumos and userland components, but we have different env.

Who are "we" in this context? Please understand the while the illumos-userland gate has historically enjoyed peer status with illumos itself, it is in reality the OI gate and should not be considered canonical in any way. AFAIK no one else uses it. One of the primary objectives of this change, which has already been made in SmartOS, is to provide distributors using the -live mechanism a reliable way to build the entire platform in a unified way, within the same consistent environment. Other distributors are welcome to adapt it for their needs. This subset of the changes necessary for that approach to work are generally appropriate for illumos itself and enable distributors to choose whether to continue building in the broken way or adopt a coherent build approach. By default, nothing changes for distributors wishing to continue delivering potentially broken bits, and the change imposes no tax or burden of any kind on them. All of this is only an interim step between where we are today and integrating all illumos dependencies into illumos, which will completely obviate the need for this workaround.

The eventual goal here, in case it's not painfully obvious, is that one should be able to do the following on any illumos system on which S10 binaries work, forever, even if it's installed with an extremely minimal core set of illumos binaries and nothing else:

- Download a set of non-illumos build tools (i.e., those not included in usr/src/tools), built against S10, appropriate to the version of illumos-gate being built, and install them in /home/user/illumos-tools/<last-illumos-version-with-a-tools-change>/ or any other desired path.
- Download illumos.
- Create an illumos.sh pointing to /home/user/illumos-tools/<last-illumos-version-with-a-tools-change>/, which should be done automatically by the build system.
- Run nightly t.
Get a complete, working set of bits that is identical regardless of the version, distribution, or other attributes of the build system.

Notice what's not required: constantly updating contents of the build system's /usr or /lib, keeping a specific build system for every release of every distribution forever, having to make sure you're building illumos on the "matching" build system, circular or bidirectional cross-consolidation flag days.

This is a very humble first step toward that world.

what we can : we can provide userland components to virtual env without re-builds for illumos builds and use it with 'chroot'

See above. chroot(2) does very little to help. All it does is isolate build environments from one another, for which purpose we already have zones.

I thought about: build SPARC builds on Intel env after GCC44 integration.
We can prepare cross-compiling toolchain.

While this change is necessary for cross-compilation to work, it is far from sufficient. chroot(2)ing does not further aid in cross-compiling unless I am misunderstanding your suggestion.

No all userland components should be building with another root path when system root "/".
Need pre-build and install dependent package before building final package.
It is argument to my proposal for 'chroot <virtual build env>'.

I don't understand. Can you please clarify? How does this affect this bug?

Actions #3

Updated by Marcel Telka over 1 year ago

  • Is duplicate of Feature #3915: Add adjuncts support to the build added
Actions #4

Updated by Marcel Telka over 1 year ago

  • Status changed from New to Closed
Actions

Also available in: Atom PDF