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?
Updated by 
Updated by 
Updated by