Multilib Development Update
We've been experimenting with multilib and I now feel it right to discuss the changes a bit further now there is something to discuss :). The work so far on this is available on the branch:
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/ml
There have been a few issues and some lessons to learn. I've also have to make some implementation decisions based on the issues we were running into. To summarise them:
a) bitbake has issues if you try and delete variables from the data store. Patches two and three on the branch fix the issues I was seeing. More details are in the commits.
b) I found the recent additional event in bitbake wasn't in the right place to optimally support multilib so I had to move the expandKeys() call. Since the only known user is the native/nativesdk classes in OE-Core, this should be ok to do at this point. Again, the commit has the specific details.
c) When adding parameter support to BBCLASSEXTEND I added some variables so the class can figure out which class is being processed and what the parameter is. Related to this is the issue that bbclass event handlers once added always get called, even if the class isn't inherited in a subsequent recipe file!
d) I switched to using <multilib>- as the prefix for multilib recipes. This was because using the ":" character didn't work out as it gets placed into paths in too many places if you add it to PN.
e) I've made the assumption that if a name in PACKAGES uses PN, its at the start.
f) The use of := in cross.bbclass makes life hard for multilib. There is a special section of multilib.bbclass devoted to handling those variables. Initially I approached this as two separate multilib classes but these are merged together now.
g) I set the TARGET_VENDOR to the horrendously ugly string "-pokymllib32". The reason is that any "-" characters in there breaks config.sub at present and other separators cause other issues. I suspect we can fix that going forward but for now it works albeit looking horrible.
h) I had to introduce MLPREFIX for use in certain places, thankfully all in places "normal" recipes shouldn't need to use it.
Summary is that you can now add:
require conf/multilib.conf
MULTILIBS = "multilib:lib32 multilib:lib64"
to your local.conf and then "bitbake zlib lib64-zlib lib32-zlib" and it will build all three configurations. Packaging of the components I've looked at is ok so far with the files in the correct directories and whilst I've not tried building an image from these, I'm optimistic :).
Since various Yocto people are scheduled to work on pieces of this, I've split the subsequent work into the following tasks for development purposes:
1) Change libdir to "lib64" for qemux86-64 and see what breaks.
2) Extend MULTILIB class extension to recipes required to build:
a) minimal image
b) LSB image?
c) Sato image?
d) world [stretch goal for 1.1]
This task also could include a better way of specifying which recipes to extend.
3) Add support to RPM packaging backend to turn modified package names into true rpm multilib packages.
4) Add support to standard opkg backend to allow parallel install of multilib variant packages (likely to be hacky at first but also include a proposal for better native opkg support of this)
5) Add support to bitbake to pass BBEXTEND parameters from options like bitbake -b where filenames are specified on the commandline
6) Create some "standard" multilib configurations (x86 32+64 bit)
7) Overhaul architecture, ABI, optimisation configuration files with a view to better structure (and ease specifying multilib configurations).
8) Reconsolidate multilib + multilibcross class differences [already done by RP now]
9) Directly support multlibs within the toolchain itself [post 1.1]
10) Investigate better TARGET_VENDOR handling for config.sub. Currently we can only have ARCH-VENDOR-linux where VENDOR cannot contain "-" but it might be possible to relax that constraint.
I'm quite pleased with the way this code "feels" now and it isn't working out too invasive into the rest of the system. I therefore think we have a solid base to start building the above tasks upon.
There are other cleanup issues it does highlight such as the convoluted mess of MULIMACH_ARCH variables, BASE_PACKAGE_ARCH, PACKAGE_ARCH and so forth but I'll save that for a separate discussion.
Cheers,
Richard
Op 21 jun 2011, om 14:14 heeft Richard Purdie het volgende geschreven:
Quoted 9 lines
We've been experimenting with multilib and I now feel it right to discuss the changes a bit further now there is something to discuss :). The work so far on this is available on the branch:
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/ml
There have been a few issues and some lessons to learn. I've also have to make some implementation decisions based on the issues we were running into. To summarise them:
[..]
Quoted 5 lines
g) I set the
TARGET_VENDORto the horrendously ugly string "-pokymllib32". The reason is that any "-" characters in there breaks config.sub at present and other separators cause other issues. I suspect we can fix that going forward but for now it works albeit looking horrible.
Angstrom has had some problems with that as well and I think DISTROs shouldn't poke TARGET_VENDOR directly, but do something like:
bitbake.conf:
# No hyphens!
DISTROVENDOR ??= "oecore"TARGET_VENDOR = "-${DISTROVENDOR}"
DISTRO.conf:
# No hyphens!
DISTROVENDOR = "foo"
regards,
Koen
Quoted 25 lines · Koen Kooi
Op 21 jun 2011, om 14:14 heeft Richard Purdie het volgende geschreven:
Quoted 9 lines
We've been experimenting with multilib and I now feel it right to discuss the changes a bit further now there is something to discuss :). The work so far on this is available on the branch:
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/ml
There have been a few issues and some lessons to learn. I've also have to make some implementation decisions based on the issues we were running into. To summarise them:
[..]
Quoted 5 lines
g) I set the
TARGET_VENDORto the horrendously ugly string "-pokymllib32". The reason is that any "-" characters in there breaks config.sub at present and other separators cause other issues. I suspect we can fix that going forward but for now it works albeit looking horrible.Angstrom has had some problems with that as well and I think DISTROs shouldn't poke
TARGET_VENDORdirectly, but do something like:bitbake.conf:
Quoted 8 lines
# No hyphens!
DISTROVENDOR ??= "oecore"TARGET_VENDOR= "-${DISTROVENDOR}"DISTRO.conf:
# No hyphens!
DISTROVENDOR = "foo"
Agreed, I think we're going to need to do something like this.
Cheers,
Richard
As I already asked before: what is the benefit having this in embedded systems?
If I am doing an embedded system I know the target hardware, and there is no need to have e.g. both 32 and 64 bit libs.
Frans.
Quoted 5 lines · Frans Meulenbroeks
As I already asked before: what is the benefit having this in embedded systems?
If I am doing an embedded system I know the target hardware, and there is no need to have e.g. both 32 and 64 bit libs.
This has been mentioned before but there are embedded use cases where the requirement is to have a low overhead OS using 32 bit libs and binaries to save memory but the main application (like a database server) runs in 64 bit mode with 64 bit libraries so it can take advantage of system memory, extra instructions or so forth. This applies to mips and powerpc as well as x86.
The implementation is fairly self contained so if you don't want multilib, you shouldn't even be aware its there...
Cheers,
Richard
Hi,
Quoted 14 lines · Richard Purdie
Quoted 5 lines · Frans Meulenbroeks
As I already asked before: what is the benefit having this in embedded systems?
If I am doing an embedded system I know the target hardware, and there is no need to have e.g. both 32 and 64 bit libs.
This has been mentioned before but there are embedded use cases where the requirement is to have a low overhead OS using 32 bit libs and binaries to save memory but the main application (like a database server) runs in 64 bit mode with 64 bit libraries so it can take advantage of system memory, extra instructions or so forth. This applies to mips and powerpc as well as x86.
Quoted 3 lines
The implementation is fairly self contained so if you don't want multilib, you shouldn't even be aware its there...
will that feature allow to build a sdk running on both x86 and amd64 hosts whatever is the build host ?
Eric
Quoted 17 lines · Eric Bénard
Hi,
Quoted 14 lines · Richard Purdie
Quoted 5 lines · Frans Meulenbroeks
As I already asked before: what is the benefit having this in embedded systems?
If I am doing an embedded system I know the target hardware, and there is no need to have e.g. both 32 and 64 bit libs.
This has been mentioned before but there are embedded use cases where the requirement is to have a low overhead OS using 32 bit libs and binaries to save memory but the main application (like a database server) runs in 64 bit mode with 64 bit libraries so it can take advantage of system memory, extra instructions or so forth. This applies to mips and powerpc as well as x86.
Quoted 6 lines
Quoted 3 lines
The implementation is fairly self contained so if you don't want multilib, you shouldn't even be aware its there...
will that feature allow to build a sdk running on both x86 and amd64 hosts whatever is the build host ?
thats a different aspect.
Although we could make a SDK which could cook up packages which run on multilibs
Quoted 6 lines
Eric
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 17 lines · Eric Bénard
Hi,
Quoted 14 lines · Richard Purdie
Quoted 5 lines · Frans Meulenbroeks
As I already asked before: what is the benefit having this in embedded systems?
If I am doing an embedded system I know the target hardware, and there is no need to have e.g. both 32 and 64 bit libs.
This has been mentioned before but there are embedded use cases where the requirement is to have a low overhead OS using 32 bit libs and binaries to save memory but the main application (like a database server) runs in 64 bit mode with 64 bit libraries so it can take advantage of system memory, extra instructions or so forth. This applies to mips and powerpc as well as x86.
Quoted 5 lines
Quoted 3 lines
The implementation is fairly self contained so if you don't want multilib, you shouldn't even be aware its there...
will that feature allow to build a sdk running on both x86 and amd64 hosts whatever is the build host ?
With OE-Core, you could already do this by setting SDKMACHINE and building one, then setting SDKMACHINE to the other and building it again.
Looking at the code, I am strongly tempted to replace nativesdk and crosssdk with the multilib code though as I think it can reuse the same functionality. That is a step beyond where we're currently at though :)
Cheers,
Richard
Quoted 4 lines · Frans Meulenbroeks
As I already asked before: what is the benefit having this in embedded systems?
If I am doing an embedded system I know the target hardware, and there is no need to have e.g. both 32 and 64 bit libs.
64-bit database on a 32-bit system.
64-bit "userspace" device drivers on a 32-bit system.
Being able to run a binary application for compatibility. This is fairly common in some embedded areas where they need something like mips o32, but the rest of the system is running n32 for performance.
etc...
This is something that most embedded systems won't use, but there are a large class of devices, primarily Carrier Grade devices, that do require mixed-mode systems.
--Mark
Quoted 8 lines
Frans.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 38 lines · Richard Purdie
We've been experimenting with multilib and I now feel it right to discuss the changes a bit further now there is something to discuss :). The work so far on this is available on the branch:
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/ml
There have been a few issues and some lessons to learn. I've also have to make some implementation decisions based on the issues we were running into. To summarise them:
a) bitbake has issues if you try and delete variables from the data store. Patches two and three on the branch fix the issues I was seeing. More details are in the commits.
b) I found the recent additional event in bitbake wasn't in the right place to optimally support multilib so I had to move the
expandKeys()call. Since the only known user is the native/nativesdk classes in OE-Core, this should be ok to do at this point. Again, the commit has the specific details.c) When adding parameter support to BBCLASSEXTEND I added some variables so the class can figure out which class is being processed and what the parameter is. Related to this is the issue that bbclass event handlers once added always get called, even if the class isn't inherited in a subsequent recipe file!
d) I switched to using<multilib>- as the prefix for multilib recipes. This was because using the ":" character didn't work out as it gets placed into paths in too many places if you add it to PN.
e) I've made the assumption that if a name in PACKAGES uses PN, its at the start.
f) The use of := in cross.bbclass makes life hard for multilib. There is a special section of multilib.bbclass devoted to handling those variables. Initially I approached this as two separate multilib classes but these are merged together now.
Quoted 5 lines
g) I set the
TARGET_VENDORto the horrendously ugly string "-pokymllib32". The reason is that any "-" characters in there breaks config.sub at present and other separators cause other issues. I suspect we can fix that going forward but for now it works albeit looking horrible.
generally _ works well with triplets but I guess we have overrides so thats ruled out.
Quoted 9 lines
h) I had to introduce MLPREFIX for use in certain places, thankfully all in places "normal" recipes shouldn't need to use it.
Summary is that you can now add:
require
conf/multilib.conf
MULTILIBS = "multilib:lib32 multilib:lib64"
I think MULTILIB = "lib32 lib64" would be nicer
Quoted 3 lines
to your local.conf and then "bitbake zlib lib64-zlib lib32-zlib" and it will build all three configurations.
will it also build binaries for both libs as well ? or just libraries
Packaging of the components I've
Quoted 61 lines
looked at is ok so far with the files in the correct directories and whilst I've not tried building an image from these, I'm optimistic :).
Since various Yocto people are scheduled to work on pieces of this, I've split the subsequent work into the following tasks for development purposes:
1) Change libdir to "lib64" for qemux86-64 and see what breaks.
2) Extend MULTILIB class extension to recipes required to build:
a) minimal image
b) LSB image?
c) Sato image?
d) world [stretch goal for 1.1]This task also could include a better way of specifying which recipes to extend.
3) Add support to RPM packaging backend to turn modified package names into true rpm multilib packages.
4) Add support to standard opkg backend to allow parallel install of multilib variant packages (likely to be hacky at first but also include a proposal for better native opkg support of this)
5) Add support to bitbake to pass BBEXTEND parameters from options like bitbake -b where filenames are specified on the commandline
6) Create some "standard" multilib configurations (x86 32+64 bit)
7) Overhaul architecture, ABI, optimisation configuration files with a view to better structure (and ease specifying multilib configurations).
8) Reconsolidate multilib + multilibcross class differences [already done by RP now]
9) Directly support multlibs within the toolchain itself [post 1.1]
10) Investigate better
TARGET_VENDORhandling for config.sub. Currently we can only have ARCH-VENDOR-linux where VENDOR cannot contain "-" but it might be possible to relax that constraint.I'm quite pleased with the way this code "feels" now and it isn't working out too invasive into the rest of the system. I therefore think we have a solid base to start building the above tasks upon.
There are other cleanup issues it does highlight such as the convoluted mess of
MULIMACH_ARCHvariables,BASE_PACKAGE_ARCH,PACKAGE_ARCHand so forth but I'll save that for a separate discussion.Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 59 lines · Khem Raj
Quoted 38 lines · Richard Purdie
We've been experimenting with multilib and I now feel it right to discuss the changes a bit further now there is something to discuss :). The work so far on this is available on the branch:
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/ml
There have been a few issues and some lessons to learn. I've also have to make some implementation decisions based on the issues we were running into. To summarise them:
a) bitbake has issues if you try and delete variables from the data store. Patches two and three on the branch fix the issues I was seeing. More details are in the commits.
b) I found the recent additional event in bitbake wasn't in the right place to optimally support multilib so I had to move the
expandKeys()call. Since the only known user is the native/nativesdk classes in OE-Core, this should be ok to do at this point. Again, the commit has the specific details.c) When adding parameter support to BBCLASSEXTEND I added some variables so the class can figure out which class is being processed and what the parameter is. Related to this is the issue that bbclass event handlers once added always get called, even if the class isn't inherited in a subsequent recipe file!
d) I switched to using<multilib>- as the prefix for multilib recipes. This was because using the ":" character didn't work out as it gets placed into paths in too many places if you add it to PN.
e) I've made the assumption that if a name in PACKAGES uses PN, its at the start.
f) The use of := in cross.bbclass makes life hard for multilib. There is a special section of multilib.bbclass devoted to handling those variables. Initially I approached this as two separate multilib classes but these are merged together now.
Quoted 5 lines
g) I set the
TARGET_VENDORto the horrendously ugly string "-pokymllib32". The reason is that any "-" characters in there breaks config.sub at present and other separators cause other issues. I suspect we can fix that going forward but for now it works albeit looking horrible.generally _ works well with triplets but I guess we have overrides so thats ruled out.
Quoted 9 lines
h) I had to introduce MLPREFIX for use in certain places, thankfully all in places "normal" recipes shouldn't need to use it.
Summary is that you can now add:
require
conf/multilib.conf
MULTILIBS = "multilib:lib32 multilib:lib64"
Quoted 7 lines
I think MULTILIB = "lib32 lib64" would be nicer
Quoted 3 lines
to your local.conf and then "bitbake zlib lib64-zlib lib32-zlib" and it will build all three configurations.
will it also build binaries for both libs as well ? or just libraries
Goal is to build the whole recipe for whatever multilibs are defined.
The packaging system(s) can then choose to install whatever is required for the runtime dependencies. (RPM can do some additional conflict avoidance, but this has to work for opkg and deb packages as well.)
--Mark
Quoted 69 lines
Packaging of the components I've
Quoted 53 lines
looked at is ok so far with the files in the correct directories and whilst I've not tried building an image from these, I'm optimistic :).
Since various Yocto people are scheduled to work on pieces of this, I've split the subsequent work into the following tasks for development purposes:
1) Change libdir to "lib64" for qemux86-64 and see what breaks.
2) Extend MULTILIB class extension to recipes required to build:
a) minimal image
b) LSB image?
c) Sato image?
d) world [stretch goal for 1.1]This task also could include a better way of specifying which recipes to extend.
3) Add support to RPM packaging backend to turn modified package names into true rpm multilib packages.
4) Add support to standard opkg backend to allow parallel install of multilib variant packages (likely to be hacky at first but also include a proposal for better native opkg support of this)
5) Add support to bitbake to pass BBEXTEND parameters from options like bitbake -b where filenames are specified on the commandline
6) Create some "standard" multilib configurations (x86 32+64 bit)
7) Overhaul architecture, ABI, optimisation configuration files with a view to better structure (and ease specifying multilib configurations).
8) Reconsolidate multilib + multilibcross class differences [already done by RP now]
9) Directly support multlibs within the toolchain itself [post 1.1]
10) Investigate better
TARGET_VENDORhandling for config.sub. Currently we can only have ARCH-VENDOR-linux where VENDOR cannot contain "-" but it might be possible to relax that constraint.I'm quite pleased with the way this code "feels" now and it isn't working out too invasive into the rest of the system. I therefore think we have a solid base to start building the above tasks upon.
There are other cleanup issues it does highlight such as the convoluted mess of
MULIMACH_ARCHvariables,BASE_PACKAGE_ARCH,PACKAGE_ARCHand so forth but I'll save that for a separate discussion.Cheers,
Quoted 8 lines
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[Multilib] a problem of SHLIBSDIR
In reply to Richard PurdieHi,
SHLIBSDIR is a central place where to store the pkg information about the shared libraries which the package would provide. In the do_package task, the function package_do_shlibs() will use this kind of information to automatically add RDEPENDS for the package being built. In the multilib situation, the SHLIBSDIR should be set to a different place form the normal version, otherwise a 32bit application might RDEPENDS on lib64-eglibc instead of the 32bit eglibc.
The following patch tries to solve this problem. Any comment?
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=llu/ml&id=1970842424c414db50058ff99c6627e3ca034a04
----------------------------------------------------------------------------------
classes/multilib.bbclass: Change the SHLIBSDIR.
Changes the SHLIBSDIR for the multilib version, so it won't mix up with the normal version.
Diffstat (more/less context) (ignore whitespace changes)
-rw-r--r-- meta/classes/multilib.bbclass 1+
1 files changed, 1 insertions, 0 deletions
meta/classes/multilib.bbclass +1 -0
@@ -30,6 +30,7 @@ python multilib_virtclass_handler () { e.data.setVar("BASE_PACKAGE_ARCH", "${TARGET_ARCH}") bb.data.setVar("PN", variant + "-" + bb.data.getVar("PN", e.data, False), e.data) + bb.data.setVar("SHLIBSDIR_virtclass-multilib-" + variant ,bb.data.getVar("SHLIBSDIR",e.data,False) + "/" + variant, e.data) bb.data.setVar("OVERRIDES", bb.data.getVar("OVERRIDES", e.data, False) + override, e.data) }
Best Regards,
-Lianhao Lu
Re: [Multilib] a problem of SHLIBSDIR
Quoted 10 lines · Lianhao
Hi,
SHLIBSDIR is a central place where to store the pkg information about the shared libraries which the package would provide. In the
do_packagetask, the functionpackage_do_shlibs()will use this kind of information to automatically add RDEPENDS for the package being built. In the multilib situation, the SHLIBSDIR should be set to a different place form the normal version, otherwise a 32bit application might RDEPENDS on lib64-eglibc instead of the 32bit eglibc.
Quoted 2 lines
The following patch tries to solve this problem. Any comment?
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=llu/ml&id=1970842424c414db50058ff99c6627e3ca034a04
I think I'd been assuming that SHLIBSDIR included the TARGET_VENDOR string as part of the triplet but it obviously doesn't and we need this.
Good catch. I think the patch is a good one to add!
Cheers,
Richard