Generating 32-bit x86 native lib while MACHINE is set to ARM(essentially) #bitbake

Generating 32-bit x86 native lib while MACHINE is set to ARM(essentially) #bitbake

[joseph.maniaci]

[-- Attachment #1: Type: text/plain, Size: 2276 bytes --]

So the instructions here ( https://docs.yoctoproject.org/next/dev-manual/libraries.html#using-multilib ) are very explicit about using the local.conf in my build directory.

I tried adding only:

require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE:virtclass-multilib-lib32 = "x86"
BASELIB:virtclass-multilib-lib32 = "lib32-openssl-native"

Since the MACHINE is already set at the top with:

MACHINE ??= "exos-x-vanadium-bmc"
DISTRO ?= "openbmc-phosphor"

Which leads to the following error:

*ERROR:  OE-core's config sanity checker detected a potential misconfiguration.*
*Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).*
*Following is the list of potential problems / advisories:*
*Toolchain tunings invalid:*
*Tuning 'x86' has no defined features, and cannot be used.*

If I try to add a machine such as MACHINE = "x86-base", or "qemux86-64", or "arch-x86", all of which have configurations in /meta/conf/machine, I get an error such as:

*ERROR:  OE-core's config sanity checker detected a potential misconfiguration.*
*Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).*
*Following is the list of potential problems / advisories:*
*MACHINE=x86-base is invalid. Please set a valid MACHINE in your local.conf, environment or other configuration file.*

The openssl library present is openssl_3.2.1, and looking at its .bb, it appears to be compatible with all of the necessary targets I'm trying to work with.

Full-ish local.conf

MACHINE ??= "exos-x-vanadium-bmc"
DISTRO ?= "openbmc-phosphor"
PACKAGE_CLASSES ?= "package_rpm"
SANITY_TESTED_DISTROS:append ?= " *"
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
USER_CLASSES ?= "buildstats"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS ??= "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
STOPTASKS,/tmp,100M,100K \
HALT,${TMPDIR},100M,1K \
HALT,${DL_DIR},100M,1K \
HALT,${SSTATE_DIR},100M,1K \
HALT,/tmp,10M,1K"
CONF_VERSION = "2"

....

# MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE: virtclass-multilib-lib32 = "x86"
BASELIB: virtclass-multilib-lib32 = "lib32-openssl-native"

[-- Attachment #2: Type: text/html, Size: 5032 bytes --]

Re: [yocto] Generating 32-bit x86 native lib while MACHINE is set to ARM(essentially) #bitbake

[Ross Burton]

On 21 Jul 2025, at 16:14, joseph.maniaci via lists.yoctoproject.org <joseph.maniaci=seagate.com@lists.yoctoproject.org> wrote:
> 
> So the instructions here are very explicit about using the local.conf in my build directory.
>   I tried adding only:
>   require conf/multilib.conf
> MULTILIBS = "multilib:lib32"
> DEFAULTTUNE:virtclass-multilib-lib32 = "x86"
> BASELIB:virtclass-multilib-lib32 = "lib32-openssl-native"
> 
> Since the MACHINE is already set at the top with:
>   MACHINE ??= "exos-x-vanadium-bmc"
> DISTRO ?= "openbmc-phosphor"
>   Which leads to the following error:
> 
> ERROR:  OE-core's config sanity checker detected a potential misconfiguration.
>     Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
>     Following is the list of potential problems / advisories:
>     Toolchain tunings invalid:
> Tuning 'x86' has no defined features, and cannot be used.
>   If I try to add a machine such as MACHINE = "x86-base", or "qemux86-64", or "arch-x86", all of which have configurations in /meta/conf/machine, I get an error such as:

You’ve told the system to build an arm target with an x86 multilib, which doesn’t make sense as arm hardware can’t run x86 code.

What are you actually trying to do?

Ross

Re: [yocto] Generating 32-bit x86 native lib while MACHINE is set to ARM(essentially) #bitbake

[joseph.maniaci]

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]

I have some native bins that need to be generated to perform some code generation before moving onto the openBMC/ARM portion of the build.

For one, it has to be configured in CMAKE via set_target_properties(genEvt PROPERTIES COMPILE_OPTIONS "-m32" LINK_FLAGS "-m32") to build in 32-bit, natively.

As of now, I'm mostly succeeding with 'DEPENDS = "openssl-native"', but get a 'libssl.so: error adding symbols: file in wrong format' error because of the incompatibility.

So I need to somehow generate the native/x86 32-bit openssl binaries but the MULTILIBS documentation doesn't seem to cover this edge case.

[-- Attachment #2: Type: text/html, Size: 713 bytes --]

Re: [yocto] Generating 32-bit x86 native lib while MACHINE is set to ARM(essentially) #bitbake

[Ross Burton]

> On 21 Jul 2025, at 17:00, joseph.maniaci via Lists.Yoctoproject.Org <joseph.maniaci=seagate.com@lists.yoctoproject.org> wrote:
> 
> I have some native bins that need to be generated to perform some code generation before moving onto the openBMC/ARM portion of the build.
>   For one, it has to be configured in CMAKE via set_target_properties(genEvt PROPERTIES COMPILE_OPTIONS "-m32" LINK_FLAGS "-m32") to build in 32-bit, natively.
>   As of now, I'm mostly succeeding with 'DEPENDS = "openssl-native"', but get a 'libssl.so: error adding symbols: file in wrong format' error because of the incompatibility.
>   So I need to somehow generate the native/x86 32-bit openssl binaries but the MULTILIBS documentation doesn't seem to cover this edge case.

So your problem is that CMake doesn’t really support “build this binary for the build host”.  You’ll need to build those binaries in a separate native recipe, and then tell the target recipe where they are to run them.  I’m presuming nobody else has tried to cross-compile this recipe before, because this is a well known limitation in CMake.

Again, MULTLIBS is _entirely_ for the target build and unrelated to your need for native binaries.

Ross

Re: [yocto] Generating 32-bit x86 native lib while MACHINE is set to ARM(essentially) #bitbake

[joseph.maniaci]

[-- Attachment #1: Type: text/plain, Size: 322 bytes --]

I wasn't expecting CMAKE to do this for me, I was just hopeful MULTILIBS was the right path, but I was starting to get the impression it only functioned for the MACHINE type specified for the build.

So hopefully all I have to do is create a native recipe that utilizes the existing openssh_3.2.1.bb and go from there.

[-- Attachment #2: Type: text/html, Size: 362 bytes --]

Re: [yocto] Generating 32-bit x86 native lib while MACHINE is set to ARM(essentially) #bitbake

[Ross Burton]

On 21 Jul 2025, at 18:21, joseph.maniaci via Lists.Yoctoproject.Org <joseph.maniaci=seagate.com@lists.yoctoproject.org> wrote:
> 
> I wasn't expecting CMAKE to do this for me, I was just hopeful MULTILIBS was the right path, but I was starting to get the impression it only functioned for the MACHINE type specified for the build.

CMake _should_ be able to do this, but it can’t.  Meson can, and even autotools makes it easy enough.

Ross

Re: [yocto] Generating 32-bit x86 native lib while MACHINE is set to ARM(essentially) #bitbake

[joseph.maniaci]

[-- Attachment #1: Type: text/plain, Size: 123 bytes --]

Interesting, I did not know. I only knew of the find_package() function. I'm learning yocto and cmake at the same time...

[-- Attachment #2: Type: text/html, Size: 134 bytes --]