On Wed, Aug 09, 2006 at 05:37:49PM -0700, Garrett D'Amore wrote: > 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.)
Here's the list (may be slightly out of date): --- cut here --- # # C++ support # lib C lib Crun lib Cstd file usr/include/demangle.h # # libm # lib m file usr/include/floatingpoint.h file usr/include/iso/math_c99.h file usr/include/iso/math_iso.h file usr/include/math.h # # Fiberchannel HBA API # lib HBAAPI file usr/include/hbaapi.h # # Admin consolidation stuff # lib usr/snadm/lib spmicommon # # WBEM stuff # lib usr/sadm/lib/wbem cimapi dir usr/sadm/lib/wbem/include file usr/sadm/lib/wbem.jar file usr/sadm/lib/wbem/cimapi.jar file usr/sadm/lib/wbem/providerutility.jar file usr/sadm/lib/wbem/solarisprovider.jar file usr/sadm/lib/xml.jar # # Netscape Security Services / Netscape Portable Runtime # dir usr/lib/mps dir usr/include/mps # # libxml2 # lib xml2 dir usr/include/libxml2 # # libxslt # lib xslt dir usr/include/libxslt # # libz # lib z file usr/include/zconf.h file usr/include/zlib.h --- cut here --- In addition, there are a (large) number of native-built programs that we run on the build machine to generate stuff for the build. These would all have to be checked for endianness issues, etc. It's not a small project; the above list is just fixing up the "pick up invalid dependencies from the build machine" problem; I had a wad to do this, but it's currently on the back burner. > > 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.) The kernel modules wouldn't be completely impossible; you'd have to use GCC, since the SUNWspro compilers don't do cross-compilation last I checked. I *think* uts is mostly clear of native compilation, except for: usr/src/uts/sun4/ml/genconst.c usr/src/uts/i86pc/ml/genassym.c which would probably have to be re-worked. Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
