Jonathan Adams wrote:
> 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):
>
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?
> --- 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.
> 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'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.
> 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!)
-- 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
