multilib_header.bbclass: Do not install the stubs for non-multilib case

Submitted by Khem Raj on Oct. 21, 2020, 9:09 p.m. | Patch ID: 177484

Details

Message ID 20201021210932.984184-1-raj.khem@gmail.com
State New
Headers show

Commit Message

Khem Raj Oct. 21, 2020, 9:09 p.m.
We mark certain headers which are not usable in multilib case through
this function, this however is a unnessary indirection when building
distros without multilib feature. Additionally it also addresses a case
where we compile baremetal software e.g. bootloaders or BPF binaries
e.g. which are a different target effectively but can be built using
same toolchain with some flags. This does not work when we always
install the stubs since the stubs require a fixed wordsize definition
and that may not be true for the BPF cases e.g. it will work fine when
multilib is enabled since that would have provided the headers it needed
say for 32bit multilib. Currently they go missing for a non-multilib
case and we end up with errors like

recipe-sysroot/usr/include/bits/long-double.h:23:10: fatal error: 'bits/long-double-32.h' file
not found
| #include <bits/long-double-32.h>

Therefore lets install these stubs only when using
multilib in distro

Signed-off-by: Khem Raj <raj.khem@gmail.com>

---
 meta/classes/multilib_header.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

-- 
2.29.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#143656): https://lists.openembedded.org/g/openembedded-core/message/143656
Mute This Topic: https://lists.openembedded.org/mt/77714884/1003190
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [mhalstead@linuxfoundation.org]
-=-=-=-=-=-=-=-=-=-=-=-

Patch hide | download patch | download mbox

diff --git a/meta/classes/multilib_header.bbclass b/meta/classes/multilib_header.bbclass
index e03f5b13b2..9ccdf46be5 100644
--- a/meta/classes/multilib_header.bbclass
+++ b/meta/classes/multilib_header.bbclass
@@ -6,7 +6,9 @@  inherit siteinfo
 # all of the ABI variants for that given architecture.
 #
 oe_multilib_header() {
-
+	if [ -z "${MULTILIB_VARIANTS}" ]; then
+		return
+	fi
 	case ${HOST_OS} in
 	*-musl*)
 		return

Comments

Richard Purdie Oct. 21, 2020, 9:47 p.m.
On Wed, 2020-10-21 at 14:09 -0700, Khem Raj wrote:
> We mark certain headers which are not usable in multilib case through

> this function, this however is a unnessary indirection when building

> distros without multilib feature. Additionally it also addresses a

> case

> where we compile baremetal software e.g. bootloaders or BPF binaries

> e.g. which are a different target effectively but can be built using

> same toolchain with some flags. This does not work when we always

> install the stubs since the stubs require a fixed wordsize definition

> and that may not be true for the BPF cases e.g. it will work fine

> when

> multilib is enabled since that would have provided the headers it

> needed

> say for 32bit multilib. Currently they go missing for a non-multilib

> case and we end up with errors like

> 

> recipe-sysroot/usr/include/bits/long-double.h:23:10: fatal error:

> 'bits/long-double-32.h' file

> not found

> > #include <bits/long-double-32.h>

> 

> Therefore lets install these stubs only when using

> multilib in distro

> 

> Signed-off-by: Khem Raj <raj.khem@gmail.com>

> ---

>  meta/classes/multilib_header.bbclass | 4 +++-

>  1 file changed, 3 insertions(+), 1 deletion(-)

> 

> diff --git a/meta/classes/multilib_header.bbclass

> b/meta/classes/multilib_header.bbclass

> index e03f5b13b2..9ccdf46be5 100644

> --- a/meta/classes/multilib_header.bbclass

> +++ b/meta/classes/multilib_header.bbclass

> @@ -6,7 +6,9 @@ inherit siteinfo

>  # all of the ABI variants for that given architecture.

>  #

>  oe_multilib_header() {

> -

> +	if [ -z "${MULTILIB_VARIANTS}" ]; then

> +		return

> +	fi

>  	case ${HOST_OS} in

>  	*-musl*)

>  		return


I have a feeling this was written specifically not to touch that
variable so that a multilib build can reuse components from a non-
multilib build and share the sstate if you configure it that way. This
change would force *all* multilibs to be stores as their own sstate and
require their own namespace.

We may therefore have to find a different control for this :/.

Cheers,

Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#143659): https://lists.openembedded.org/g/openembedded-core/message/143659
Mute This Topic: https://lists.openembedded.org/mt/77714884/3616849
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [michael@yoctoproject.org]
-=-=-=-=-=-=-=-=-=-=-=-