On Sat, 2011-08-06 at 15:56 -0500, Kumar Gala wrote: > I'm looking at trying to get multilib working for powerpc. However > I'm a bit lost in how this is suppose to work from a few different > perspectives: > > 1. from user perspective (I'm starting with a 64-bit build in /lib64 and > adding 32-bit that would be in /lib): > > (i've added in local/conf): > require conf/multilib.conf > MULTILIBS = "multilib:lib" > DEFAULTTUNE_virtclass-multilib-lib = "powerpc"
Rather than use the identifier "lib", I'd use an identifier like "lib32" which is unlikely to be found in a recipe name. Therefore something like: require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "powerpc" > What should this end up producing? Do I get a 32-bit set of libs built > automatically? What else do I need to do? This will enable a number of other built targets such as "lib32-bash". You can also construct images that are mixtures of the various multilibs (e.g. install both openssl and lib32-openssl). > 2. From a infrastructure point of view: > > * Do have a single compiler that is multi-arch or 2 compilers? (not sure how > the x86_64 toolchain works today) At this point we've gone for 2 compilers. This was a conscious choice to avoid additional complexity and allow us to get the core functionality working. We can support merged toolchains at a future date with appropriate toolchain configuration and ASSUME_PROVIDED declarations. > * what areas should I investigate that might need tweaking that are arch > specific? There should be very little beyond the places you've already changed that should need tweaking. The only issues may be due to this being very new code. > * should I see different task names for the new multilib builds? (or the > 32-bit specific builds?) multilib.conf lists the recipes that will become multilib enabled. I've just merged a patch to extend this list to include the various ones that have been tested. The ultimate plan is not to require that list and its just a transition point. Cheers, Richard _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
