Re: [SEToolkit-developer] Crosscompiling for unified packaging

[Alex K. <ale...@gm...>]

On 03/04/07, Dagobert Michelsen <da...@ba...> wrote:
> Hi Alex,
>
> your post seems to come from you directly instead of the mailing list. I cited
> all for archive purpose. Have you just replied to my last mail or do I need to
> tweak something in Mailman?
>

Strange - the first one went back to the list direct, so I didn't even
think about it... looks like there's I need to reply to all (which is
what I'd normally do, but didn't even bother looking in this
instance).

> Von "Alex Kiernan" <ale...@gm...> (Mon, 2 Apr 2007 16:32:08 +0100):
> > On 02/04/07, Dagobert Michelsen <da...@ba...> wrote:
> > > Von "Alex Kiernan" <ale...@gm...> (Mon, 2 Apr 2007 10:15:15 +0100):
> > > > On 01/04/07, Dagobert Michelsen <da...@ba...> wrote:
> > > > > > Excellent - it was well worth committing it; your comments managed to
> > > > > > trigger the idea of how to make it build the "right" version for a
> > > > > > particular platform - I'll commit it shortly (I seem to have some
> > > > > > network problems at the moment).
> > > > >
> > > > > This sounds difficult to me. It must produce the correct version for
> > > > > the compiling host regardless of the compiler (SS11 or gcc) and it
> > > > > must be possible to easily overwrite this. I used setting CC to
> > > > > "/opt/SUNWspro/bin/cc -xarch=generic64" which would certainly collide
> > > > > with setting made at a different place in configure.
> > > >
> > > > My thought was to write an autoconf test which did:
> > > >
> > > > #ifdef _LP64
> > > > exit(0);
> > > > #else
> > > > exit(1)
> > > > #endif
> > > >
> > > > which will pick a 64 bit compilation option, no matter how specified,
> > > > then compare the result with what `isainfo -b' says. But you do then
> > > > need another autoconf option which says don't do this magic - on
> > > > balance, perhaps the warning is the better option. Also once you need
> > > > to do `isainfo -b', the option of cross-compiling goes out of the
> > > > window.
> > >
> > > Not necessarily. I'll expect a warning if the built binary is not suitable
> > > for the running kernel. A test with kvm_open might be more meaningful.
> > > On crosscompilation the binary won't execute and would issue a warning too.
> > >
> >
> > On a cross compile, it'd pick up the cross-compile setting from the
> > AC_... macro - for that I'd just set it to success (on the assumption
> > that if you're building using a cross you really ought to know what
> > you're doing).
>
> Ok.
>

I'll start sorting the pieces so you get a warning when it knows its
likely to be wrong.

> > > > > Should we attempt to port/investigate/document how the examples
> > > > > match to D-scripts?
> > > >
> > > > I'm not sure its worth the effort (but I guess it depends to an extent
> > > > on whether we think anyone is using se for anything more than an
> > > > orcallator base).
> > >
> > > This may be a good finger exercise for me (and others?) to become
> > > more familiar with kernel structures and D-Trace.
> > >
> > > Here are the next steps I planned:
> > > - put out a RICHPse-package for 3.4.1 on SF. The changelog must be
> > >  adjusted for the fixed issues.
> > > - repackage for blastwave.org
> > >  For this the package-name needs to be configurable. Ad hoc I would say
> > >  autoconf is not needed for this but I haven't checked the code yet.
> > >  The integration of a current version of orca (r529) needs some packages
> > >  which are installed during Orca install. This dependency can be resolved
> > >  easily with dependencies to existing Blastwave-packages. I am unsure
> > >  how to handle this for the RICHPse-style package. Any ideas?
> > > - version 3.5.0 should include autoconf (of course) and a current Orca.
> > >  Further ideas?
> >
> > I'd be inclined to split orcallator from setoolkit and orca (which
> > actually is what we've done - we install an setoolkit and orcallator
> > package on machines, and then an orca package elsewhere).
>
> Should orcallator go to orca or stay with setoolkit?

My view is orcallator should either be separate, or part of setoolkit,
but definitely not part of an orca package. I like orcallator
separate, because that way it's clear what auto-started functionality
is being delivered (but if it was part of setoolkit, I wouldn't argue
too hard).

> Should it be necessary to install orca just for the orcallator?

No - here we install an setoolkit and an orcallator package on every
host, then rsync all the data onto a pair of central servers which
then runs orca.

> Maybe we should put the updated libs in orca and continue
> to include a current version of the orcallator.

Certainly we should pull the updated libs, though there are a couple
of new classes which orcallator uses which weren't in setoolkit
originally (the workload stuff) - we'd need to clarify the licensing
on those (I think).

-- 
Alex Kiernan