Darren J Moffat wrote: > Garrett D'Amore wrote: >> OpenSolaris currently requires that you build it on a version of Solaris >> that is very close to the version that you are building. E.g. you can't >> build OpenSolaris on Solaris 9 (or even early releases of Solaris 10.) > > Lets nit pick on some important terminology first :-) > > I believe you are talking about the ON consolidation only. > OpenSolaris is a community/project that is built from multiple > consolidations (so far they match 1:1 (I believe) with what is in > Solaris plus some projects and communities for work in progress).
Yes, I'm referring to ON. (Primarily because that is what most interests me, though one could imagine doing this for other consolidations and having those consolidations reference an ON workspace. That is how I did it with unbundled Alternate Pathing ages ago.) > >> Has anyone given any thought to convincing OpenSolaris to use its own >> proto area (populated by the install_h target or somesuch) instead of >> assuming local system headers? > > That is all very well for the stuff in ON that only depends on stuff > in ON. However there are a few cases from time to time where ON > depends on stuff from another consolidation. In those other > consolidation dependency cases we assume that the local build machine > has the relevant header files and libraries in the canonical location. Hmm... apart the compilers themselves, what does ON depend on other than itself? Depending on headers from other consolidations seems "weird". (We had some cases of something like that with shared interfaces between ON and the E10K SSP, IIRC, but I think the necessary headers were committed to ON.) > > There is also the problem in ON with library build dependencies not > being fully specified and we lazily pickup from the build machine. Yes, the dependencies would need to be corrected. > > Best I can tell it is more than just doing an install_h to get the > headers in place we would also need to fix the libraries build so that > they fully express all dependencies and build them in the correct order. > > If I remember correctly Peter Memishian has looked at this a little > and came up with the idea of first building "stuff" libraries based on > the linker mapfiles on a first pass. The build would then run as > normal and use the proto area stub libs. > > I'm certainly interested in making this work, just wish I had time to > dedicate to it. > I might have cycles for it, because it would solve some problems for me. I like Peter's idea, but I'd suggest starting with a first path that just considered the kernel/kernel modules. That would be a baby step to get the Makefiles and header problems worked out, before tackling library dependencies. It would also be immediately useful to a non-trivial number of kernel developers, I think. (Most of the userland code out there tends to make at least some effort at being portable as-is anyway, unlike kernel code. There are a lot of exceptions, but the point is that I suspect that code is in the minority -- even for code bundled with ON.) -- Garrett D'Amore, Principal Software Engineer Tadpole Computer / Computing Technologies Division, General Dynamics C4 Systems http://www.tadpolecomputer.com/ Phone: 951 325-2134 Fax: 951 325-2191 _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
