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 _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core