On Wed, Aug 09, 2006 at 06:21:38PM -0700, Garrett D'Amore wrote: > >>> > >> 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): > > > > Of the list you provide below, I can really only see the C++ runtime, > libm, and Fibrechannel HBA API as things that ON "depends on" (at build > time.) > > I'm surprised that the HBAAPI is located here and not part of ON. > > Does ON truly depend on any of the reset of it at build time?
libm is kind of necessary to do any interesting floating point stuff in C, and libc uses it, so yes. libxml2 is used by zones and smf and poold, and possibly others. libxslt is used by metassist, part of SVM. libz is used all over the place. The HBAAPI stuff is insane, but we use it in cmd/picl/plugins/sun4u/cherrystone/psvcpolicy/psvcpolicy.c. I think the portable runtime stuff is used in libldap5 (I could be wrong). The WBEM stuff is used to compile all of the solaris-provided WBEM backends. I generated this list by looking at what we #include and link against during the build process. This is the full list, as of some point in the past. It may not make sense, but it's how everything is put together at the moment. > > --- 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. > > > > Yes. But only to support cross-compiling across architectures. To > support building Solaris Nevada/SPARC on Solaris 8 SPARC, for example, > you wouldn't need to do that. True; they would need to be checked for reliance on post-Solaris 8 features, though. > > 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 never meant to imply its a small project. But I think it is doable, > and worthwhile. I do, too; the above list was from a first-pass at making it work. There's actually an additional problem which I've talked to the linker folks about, but I haven't filed a bug for yet: when you link with '-z defs', (as we do), ld(1) pulls in all of the referenced objects. If an object references an object via a RUNPATH entry (i.e. something which links against libnspr4.so in /usr/lib/mps), ld(1) will *use* the runpath directly. This makes is tricky to do anything but a symlink farm to the "allowed" objects in /. There's no way to specify a "runpath prefix" to work around this behavior; the bug/RFE I need to file is to allow for one. > >>> 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. > > > > Actually, this is only true for cross-architecture building. I don't > want to do that, because frankly I truss GCC less than Studio, at least > for Solaris sources. > > It does seem to me that it would be pretty easy for the compiler group > to make their compiler able to cross compile. They have code generation > and optimization for both platforms, so apart from fixing any endianness > issues in _their_ code, it should be doable. > > But this is moot for one major portion of the problem, which is cross > compilation from one _release_ of Solaris to another, _without_ changing > the processor architecture. <nod> It would definitely be nice. > > 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. > > > > Those probably are a non-issue unless we get architecture > cross-compilation working. I wouldn't even bother with that unless the > compilers group makes cross compilers available. (It would be really, > really nice if they would do that!) Agreed. If you're interested in working on this, I can put together my notes from the last time I worked on this (a few months back; my first big push was a year or so ago). Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
