Re: Proposed Multilib Implementation Brainstorming

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2011-04-05 at 16:28 -0700, Jeremy Puhlman wrote:
> > 
> > To do this I'm thinking of a new set of include files of the form
> > conf/machine/include/multilib-xxxx.inc, similar in nature to the
> > tune-xxx.inc files. A given setup would include each of the multilibs it
> > requred. Each multilib include file would look something like:
> > 
> > conf/machine/include/multilib-x86-lib32.inc:
> > 
> > MULTILIBS += "lib32"
> > 
> > BASE_PACKAGE_ARCH_virtclass-multilib-lib32 = "core2-lib32"
> > TARGET_CC_ARCH_virtclass-multilib-lib32 = "-m32 -march=core2"
> > PACKAGE_EXTRA_ARCHS += "core2-lib32"
> > 
> > libdir_virtclass-multilib-lib32 = "${exec_prefix}/lib32"
> > base_libdir_virtclass-multilib-lib32 = "${base_prefix}/lib32"
> > 
> > i.e. use overrides to change the target cc architecture specifying the
> > required flags to the compiler and also alter the library paths as
> > required.
> > 
> > I'm envisaging passing an optional new parameter to classes in
> > BBCLASSEXTEND so for example the definition of a multilib could look
> > something like:
> > 
> > BBCLASSEXTEND_append = " multilib:x86-lib32"
> > 
> > and all the multilib class would need to do is to manipulation of
> > variables including OVERRIDES in a similar way to native.bbclass with
> > the complication of handling the parameter.
> 
> It is possible to do it with out changes to bitbake, but adding
> parametrization to BBCLASSEXTEND would be useful in a number of ways,
> and much more elegant then doing it with out it, and cleaner for that
> matter. Unrelated to multilib, would the full path to the sub parameters
> be configurable via the extended class? i.e. "conf/machine/include/" be
> a configurable value from the multilib class?

I've been thinking this would be the other way around. The act of adding
some conf/machine/include/* files would then trigger the inheritance of
the multilib class with the parameter specified at the point of the
inclusion.

> > For opkg there are multiple levels we can take the integration to. It
> > should be possible for example to install the "weaker" multilibs first,
> > then just install the stronger ones over the top, assuming any file
> > overwriting is ok and can be ignored. 
> 
> If there isn't any kind of compartmentalization of binaries(i.e. the
> alternate abi having a set of packages that only contian runtime libs),
> wouldn't this render the package management on opkg based systems post
> install largely useless other then just adding new components?

Its use case specific and I agree the above is hacky. It would be better
to have that option with known caveats that none at all though.

>  Most
> applications are getting better about it(openssl comes to mind), but
> some may still place arch specific headers in common locations. Many
> like openssl started switching over to arch wrapper headers, but there
> may be some stuff still lurking out there. Could probably be handled on
> a case by case basis.

Yes, we've going to have to watch for this kind of issue and get it
fixed as and where we find it.

> I have been kicking around a still broken POC implementation to this for
> a bit, but this is basically the line of thought(minus the
> parametrization of BBCLASSEXTEND) for a while on the subject. This looks
> mostly right to me.

Great, thanks for the feedback!

Cheers,

Richard