Jonathan Adams wrote:
> 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.
>
See my comments above -- I would expect libm to be necessary to build
much of userland. :-)
By the way, libm now appears to be available under CDDL as well. Is
there any compelling reason that this remains a separate consolidation?
(How closely tied is it to the compilers? Maybe it doesn't need special
treatment anymore than does, say, libc?)
> 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.
>
See the earlier e-mails. If these are "foundation" technologies, then
maybe we really should import them into ON. Yes, it makes tracking
external versions harder, but IMO, it actually makes ON a bit more
robust because random odd-ball changes in sfw are unlikely to break ON.
And, in the worst case, if SFW needs to churn more rapidly than ON can
keep up, then SFW can have its own copies and link against those using
the -R linker flag. I suspect, however, that the churn in these
libraries has slowed down (certainly there hasn't been any interface
changes in libz for years now. I don't know how stable the libxml2 and
libxslt interfaces are these days.)
> The HBAAPI stuff is insane, but we use it in
> cmd/picl/plugins/sun4u/cherrystone/psvcpolicy/psvcpolicy.c.
>
Yikes. Well, again, maybe the header belongs in ON. This cross
dependency seems bizarre.
> 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.
>
The question I have for a lot of this stuff, shared headers and the
like, is who "owns" the interface? (From the standpoint of which
consolidation, not which technical group.) It seems like ownership of
shared interfaces should probably belong in the OS group. Certainly
that is how we approached the service processor interfaces for the E10K
years ago.
If this approach is taken, then key headers (like, maybe the HBAAPI
header?) can be moved into ON as needed.
It is also possible, I think, that some of the interfaces boundaries for
some of these projects may not be as cleanly defined as they could. In
other words, maybe a header and libraries isn't the right place for a
WEBM boundary -- maybe a better place to define it is in an ioctl or
picld or somesuch boundary. (I know almost nothing about WEBM, so I'm
talking out of my hat, but hopefully at least the illustration makes sense.)
>>>
>>> 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.
>
Yes. I suppose CTF/mdb/DTrace is likely to create a challenge here.
But apart from those, I think most of them would be pretty clean.
>
>>> 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.
>
Hmm... well, we do need someway to override that.
>
>>>>> 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.
>
FYI, I posted an inquiry to the compilers group about this in particular.
>
>>> 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).
>
Sure. I want to at least fix the kernel compilation as a first step. I
have verified that it does not look in the proto area built by the sgs
target at all. So /usr/include has potentially a big impact on the
compiled kernel and associated modules.
-- Garrett
> Cheers,
> - jonathan
>
>
--
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
