On Mon, 2011-08-08 at 09:32 -0500, Kumar Gala wrote: > On Aug 8, 2011, at 7:58 AM, Richard Purdie wrote: > > 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" > > is 'lib32' utilized anywhere else or just to match these things > together? Just want to be clear that I'd expect 32-bit libraries to > be in /lib/
The actual baselib comes from: BASE_LIB_tune-powerpc = "lib" i.e. from the tune you selected so it would be lib unless you overrode this value. The "lib32" is just used as an identifier in this scenario. > >> 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). > > What would I expect w/regards to RPM or ipk's that are created? How > does one tell the 32-bit vs 64-bit? It depends on the package backend and what its capabilities are. Offhand I think we settled on rpms having the same name but being placed in a different directory and have the package architecture changed. The names of ipks are changed to include the "lib32-" prefix. > >> 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 would they be called or how are they distinguished? They're installed into different paths and the lib32- prefix is also used for the different targets. > >> * 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. > > I feel like I tried 'enabling' multilib on ppc and didn't see anything new > built for the 32-bit libs. Did you try something like "bitbake lib32-bash" though? Cheers, Richard _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
