Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Yocto native build of some recipes for 32 bit on 64bit system

Tags:

yocto

bitbake

I am trying to build some native packages as 32bit in yocto (2.6.1 actually, on a 64bit linux). My target does not use multilib at all. Let's say I am building recipe a which needs (all build-time, linking statically) package b as well as zlib and libcrypto. I manage to build a and b as 32bit by simply adding -m32 to the gcc calls, and linking/running works fine. However, the build system does not know about it and puts everything under work/x86_64-linux.

I have to use pre-build 32bit zlib and libcrypto libraries for this to work because yocto will of course try to give me the 64bit versions of zlib and libcrypto when I let it (DEPENDS_class-native = "b-native zlib-native openssl-native"), resulting in a linker error. It would be nice to have yocto build them for me in the correct architecture.

I have experimented with TARGET_ARCH and BUILD_ARCH but it either does not change it to 32bit at all, or it gives an error that it does not find e.g. quilt as 32bit (to apply patches, which could/should be done using 64bit quilt).

The specific errors are prepended by a lot of

WARNING: a-native-1_0.4-r0 do_prepare_recipe_sysroot: 
Manifest /yoctoroot/work/sstate-control/manifest-i586-quilt-native.populate_sysroot 
not found in i586 (variant '')?
....
WARNING: a-native-1_0.4-r0 do_prepare_recipe_sysroot: 
Manifest /yoctoroot/work/sstate-control/manifest-i586-openssl-native.populate_sysroot 
not found in i586 (variant '')?
....
ERROR: a-native-1_0.4-r0 do_patch: 
Command Error: 'quilt --quiltrc /yoctoroot/work/i586-linux/a-native/1_0.4-r0/recipe-sysroot-native/etc/quiltrc push' 
exited with 0  Output:    /bin/sh: quilt: command not found
ERROR: a-native-1_0.4-r0 do_patch: Function failed: patch_do_patch
ERROR: Logfile of failure stored in: ...

when I add

BUILD_ARCH_native = "i586"
BUILD_ARCH_class-native = "i586"
TARGET_ARCH_native = "x86"
TARGET_ARCH_class-native = "x86"

to the a and b recpies.

The packages a and b are not native-only, they are also built for the target and use BBCLASSEXTEND = "native" to enable native builds; a solution should ideally not break the target builds and not all other native stuff in the ecosystem.

The reason why I want them 32bit at all is that the packages a and b do intermixed pointer/integer arithmetic which breaks when the sizes of these datatypes do not match; I would appreciate if I would not have to change these sources. Am I asking too much?

Thanks in advance for any thoughts and directions!

like image 622
Stefan Hegny Avatar asked Nov 16 '22 11:11

Stefan Hegny


1 Answers

I got it going, but it does not feel much better than using pre-built binaries and seems not feasible if there were more than just two dependencies.

I added the following lines to the a and b recipes (well, the BBCLASSEXTEND was already there):

BUILD_ARCH_class-native = "i586"
TARGET_ARCH_class-native = "x86"
PATCHTOOL_class-native = "patch"
BBCLASSEXTEND = "native"

This makes the quilt error go away and puts them in the i586-linux directory instead of x86_64-linux.

For zlib and openssl, I copied the original recipes into one of my own layers (including patch files etc.) as zlib32bitxyz-native and openssl32bitxyz-native, added these lines:

BUILD_ARCH = "i586"
TARGET_ARCH = "x86"
PATCHTOOL = "patch"
inherit native
BP = "openssl-${PV}" # or zlib

as well as replacing ${PN} by openssl and zlib respectively at some places.

Making them build 32bit was a nop for openssl, it simply worked.

For zlib, things started with not finding an xz to unpack the downloaded archive. I added a link to my /usr/bin/xz in the hosttools directory manually.

Additionally, I tweaked

do_configure() {
    CFLAGS="-m32" ./configure --prefix=${WORKDIR}/recipe-sysroot-native/usr --libdir=${WORKDIR}/recipe-sysroot-native/usr/lib --uname=GNU
}

which makes the build 32bit and removes the build of unused shared stuff.

Then, in recipe a, the native depends now reads

DEPENDS_class-native += "b-native openssl32bitxyz-native zlib32bitxyz-native"

and all builds and links okay (but with a lot of warnings, see question) and comes out 32bit.

If this gives you a shudder, feel free to guide me the correct way.

Edit: What does not work

One night, I thought, why not simply use zlib_%.bbappend and openssl_%.bbappend in my layers containing simply only

BUILD_ARCH_class-native = "i586"
TARGET_ARCH_class-native = "x86"
PATCHTOOL_class-native = "patch"
BBCLASSEXTEND = "native nativesdk"

plus, for zlib, the do_configure_class-native as above, and then replace in recipe a DEPENDS_class-native += "b-native zlib-native openssl-native"

For a this does work!! However, it breaks nearly everything else native, e.g. the do_configure from kmod_native by

| checking for zlib... no
| configure: error: Package requirements (zlib) were not met:
| 
| No package 'zlib' found
| 
| Consider adjusting the PKG_CONFIG_PATH environment variable if you
| installed software in a non-standard prefix.
| 
| Alternatively, you may set the environment variables zlib_CFLAGS
| and zlib_LIBS to avoid the need to call pkg-config.
| See the pkg-config man page for more details.
| NOTE: The following config.log files may provide further information.
| NOTE: /media/hegny/1.42.6-5592/yo419/tisdk_workdir-external-arm-toolchain/work/x86_64-linux/kmod-native/25+gitAUTOINC+aca4eca103-r0/build/config.log
| ERROR: configure failed
| WARNING: /media/hegny/1.42.6-5592/yo419/tisdk_workdir-external-arm-toolchain/work/x86_64-linux/kmod-native/25+gitAUTOINC+aca4eca103-r0/temp/run.do_configure.28023:1 exit 1 from 'exit 1'
| ERROR: Function failed: do_configure (log file is located at /media/hegny/1.42.6-5592/yo419/tisdk_workdir-external-arm-toolchain/work/x86_64-linux/kmod-native/25+gitAUTOINC+aca4eca103-r0/temp/log.do_configure.28023)
ERROR: Task (/media/hegny/1.42.6-5592/yo419/tisdk/sources/oe-core/meta/recipes-kernel/kmod/kmod-native_git.bb:do_configure) failed with exit code '1'

Ain't there anyhing like a native multilib which is simple?

like image 95
Stefan Hegny Avatar answered Dec 27 '22 18:12

Stefan Hegny