Mike Kupfer wrote:
>>>>>> "GD" == Garrett D'Amore <[EMAIL PROTECTED]> writes:
>>>>>>
>
> GD> Is there anyone else interested in being able to cross-compile
> GD> Solaris like this?
>
> I'm interested, and I'm sure others are. But I expect it to be a lot of
> work, particularly for cmd, and I can't justify to myself spending time
> on it anytime soon.
>
Why so much for cmd? I would have thought most of cmd would have been
straight-forward. The biggest problems, I think, will be from code that
has its own ideas of what compilation flags should be used. Most of the
code, though, can probably just do with changes to some common Makefiles
to adjust C flags.
Of course, libraries will still need to be built first, but assuming
that, the link stage can link against libraries in the proto area
instead of lazy linking against /usr/lib.
> GD> I suspect such a change would require non-trivial ARC review.
>
> ARC review: unlikely. Most of the work would be in the makefiles.
> You'd only need ARC review if you started changing interfaces in the
> (product) code, which seems unlikely for a project like this. When I
> split the source tree into open and closed parts, there was no ARC
> review at all.
>
> C-team review: yes, though I suspect that it could be handled by a few
> meetings with key C-team members.
>
Hmm... well, the problem is that there will be some serious Makefile
hackery involved. And in an ideal world, the object directories would
be separate, so that you could compile both x86 and sparc in the same
workspace. Again, makefile churn. Not rocket science though.
I -know- ARC review is required for interface changes, but I would have
thought there would have to have been some wider review of a major
change like what I'm proposing. Somehow it just sounds "too easy". :-)
Would it be worthwhile for me to start the process for the kernel
sources in a separate tree and post them somewhere for folks to look
at? Really, it shouldn't be too bad at all.
> By the way, in an earlier mail you mentioned packaging churn as a
> possible result of cross-compilation support. That really shouldn't
> happen. The packages reflect the final bits that are delivered, not how
> they were derived from the sources.
>
Hmm.... I don't recall stating anything about that. But I totally
agree with you packages are based on the final bits, and how you get
there pretty much doesn't matter. (It might be nice to have some
attribute to assist in debugging, but right now OpenSolaris doesn't
"support" users building their own packages anyway.)
-- Garrett
> cheers,
> mike
>
--
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
