Use rootfs when cross-compiling

[matt-duke]

I'm trying to figure out the correct way to compile sources that require a sysroot parameter. The specific example is when cross-compiling QT5 from source for an Nvidia Jetson.

My bitbake recipe looks like the following:

LICENSE = "gpl-2.0"
DESCRIPTION = "QT5 source"
MAINTAINER = "<email@company.com>"
DPKG_ARCH = "arm64"
DEBIAN_BUILD_DEPENDS = "libgstreamer-plugins-base1.0-dev, \
                        libgstreamer1.0-dev, \
                        libxrender-dev, \
                        libxi-dev, \
                        libfontconfig1-dev, \
                        libudev-dev, \
                        libssl-dev, \
                        libgles2-mesa-dev, \
                        libgl1-mesa-dev, \
                        libglib2.0-dev"
PV = "0.1"

SRC_URI = "https://download.qt.io/official_releases/qt/5.15/5.15.2/single/qt-everywhere-src-5.15.2.tar.xz"
SRC_URI[sha256sum] = "3a530d1b243b5dec00bc54937455471aaa3e56849d2593edb8ded07228202240"

SRC_URI += "file://deeptrekker-qt5.conf \
            file://rules \
            file://linux-jetson-nano"

inherit dpkg-raw

do_install() {
    install -v -d ${S}/debian/source/
    cp -r ${WORKDIR}/qt-everywhere-src-5.15.2 ${S}/qt-everywhere-src-5.15.2
    cp -r ${WORKDIR}/linux-jetson-nano ${S}/qt-everywhere-src-5.15.2/qtbase/mkspecs/devices
}

do_prepare_build_append() {
    # Speed up builds by not including qt5-everywhere in source deb
    install -v -d ${S}/debian/source/
    echo 'tar-ignore = qt-everywhere-src-5.15.2' > ${S}/debian/source/options
}

This recipe configures QT by customing the rules file:

override_dh_auto_configure:
    printenv
    cd qt-everywhere-src-5.15.2 && \
    ./configure \
        -device linux-jetson-nano \
        -device-option CROSS_COMPILE=$(DEB_HOST_GNU_TYPE)- \
        -prefix /usr/local/qt5 \
                ...

I would like to add -sysroot ${BUILDCHROOT-TARGET} and -hostprefix ${BUILDCHROOT-HOST}, where these variables point to root filesystems environments (seem to be called buildchroots). Compiling QT5 in particular seems to require the sysroot argument when compiling using pkgconfig and will fail if the path is not given.

ERROR: Feature 'pkg-config' was enabled, but the pre-condition 'tests.pkg-config' failed.

What is the correct way to do this using ISAR? The isar-bootstrap-host/target recipes seem to accomplish what I would like, but I don't see a way to use these environments in subsequent recipes.

Thank you for your help.

[jan-kiszka]

What speaks against using the original Debian packages? If you see deficits in their packaging, file bugs.

In the meantime, you can rebuild those packages with the help of Isar, applying pending Debian patches on top.

Only if you find a package that has no Debian packaging yet, also not on salsa.debian.org, it makes sense to think about writing that from scratch.

[matt-duke]

There is no Debian package for Qt5 that includes our modifications. We are running this on an embedded system that requires some customization. Besides, we have internal applications that will need to be built in a similar fashion that has no Salsa package.

Normally it would be relatively straightforward to pull a sysroot from the system (or use bootstrap and chroot to generate one) then cross compile by directing the build tools to the sysroot for shared libraries. I was hoping ISAR would be able to do the same, but in a more reliable and consistent way.

[jan-kiszka]

Bring your requirements upstream. Compiling and the maintaining something as large as Qt yourself is very likely the wrong approach.

[matt-duke]

I appreciate the advice and will certainly take that into consideration. That being said, this question is more general than Qt. Does ISAR allow recipes to directly access the buildchroot directory? For example, I might want to add or customize a configuration file in the base image without creating a deb package. I thought this might happen in buildchroot.bbclass, but it looks like only a few directories are mounted to the host there.

Thanks again for your help.

[amikan]

If speaking about buildchroot access you should know that building of the package is already running inside target or host chroot based on ISAR_CROSS_COMPILE variable. So you can't and shouldn't access to host buildchroot from target buildchroot and vice versa. As Jan already mentioned the best way is to use already debianized Qt sources. If you have some patches whey can be placed inside your layer and applied on top of the sources obtained from apt://

[jan-kiszka]

You can do a lot of evil hacks in Isar, e.g. https://github.com/siemens/meta-iot2050/blob/639e07fde39d0f66c72d032e0e6222d6de1eb93c/recipes-app/mraa/mraa_2.0.0.bb, overcome meanwhile via https://github.com/siemens/meta-iot2050/commit/4214e60acfe98e79b3feeb77b926f2c27e343e75 (which will be automatically obsoleted via bookworm). Still, it is not recommended to go down this road because it will easily break in the future and not solve your problems sustainably. And Isar is about to switch to sbuild internally which will strengthen the isolation between recipe and build environment further - and break creative local "solutions".

[matt-duke]

Closing, not an ISAR issue.