From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6755821036247187456 X-Received: by 2002:a1f:e901:: with SMTP id g1mr6354551vkh.95.1573199997002; Thu, 07 Nov 2019 23:59:57 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:6102:2261:: with SMTP id v1ls794705vsd.11.gmail; Thu, 07 Nov 2019 23:59:56 -0800 (PST) X-Google-Smtp-Source: APXvYqwVUTfa2SCRS1NpilrXjIa4LWJtYYpiXa+RGmvQ1wn4OY5qX4sRMDq56Pkpcz/0PbKnCYsR X-Received: by 2002:a05:6102:7ce:: with SMTP id y14mr6707102vsg.220.1573199996656; Thu, 07 Nov 2019 23:59:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573199996; cv=none; d=google.com; s=arc-20160816; b=aoeUn1Ex9NjySPRWghR3wlEJcBbsgjGq+PI1vlUjcmNkP3CiBrEXpqiY8PEH6mc2mg uclcc6llNS+1MBXFh1IzROa71EwmTz/dVnCs03qHXmP/En9xcVNQ8oUfxE0+LxW0WvG5 tyag64srnz9imsyQY/r1FwmGGaBhMI5oueeaGKQ5mt7/DFb0gkw2jyTs//kUzulQlxfC lFfMKs6Y+Mkr/17FAWNykODLa0Pcw4QI+pTAqCjT8Prkb6ynevDdb0gxENU4iAqXwkuF nS8CYrxfLEOSEhUmlbE/S0OnYnGCOk1YPPZ+GGTnVn6mj2e+aO897ol40Q2aR/ShNgtO OHjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-language:content-transfer-encoding:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject:ironport-sdr :ironport-sdr; bh=cVHJdi6x4+t4PjUIRNXOAvEdlI2GCc9YSRN0qECeehc=; b=S9Rijc30/28E0xijSrosnCKpsx6jxq8cNo9a2pfQVNZZchZT33ogkiFUYNbeQj7TqV f/FLdqC0a9AYGDVVDHTQTMCsKtGqElqADfrutgMQ8yZhj28QPTPn4Pnw6e6bzBZirOh3 zl+zmomW0YfVKzI6R0o3pHpZBNRMgp2xDK0sqSzlbWIFKUQpIFTsdxrDTHiqaRAAsvyN tbzrlNiFRIa8F1rd8EqyCXkRLN7Zp6GvkidNBfyMZoxCvwz6ClEn7lluj7Li4ipLnffM FfwZ0V8KEu88a9LauvPEcVEdJl5yEwJdOzIF6qu4DyKoNzVTDQNTS4tP04sytMciuDMw JMuA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of cedric_hombourger@mentor.com designates 68.232.141.98 as permitted sender) smtp.mailfrom=Cedric_Hombourger@mentor.com Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com. [68.232.141.98]) by gmr-mx.google.com with ESMTPS id s197si331380vkd.5.2019.11.07.23.59.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Nov 2019 23:59:56 -0800 (PST) Received-SPF: pass (google.com: domain of cedric_hombourger@mentor.com designates 68.232.141.98 as permitted sender) client-ip=68.232.141.98; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of cedric_hombourger@mentor.com designates 68.232.141.98 as permitted sender) smtp.mailfrom=Cedric_Hombourger@mentor.com IronPort-SDR: fUkea1jIDR9+78hHOxCDlx8OOfXM2+C76UoPVJ5UToPYcFRBw9wgBlTcnkQ9PJ3JcPT3UdQnzV f3USxZ1egJwd1LlQwRCvXjOHibfqG6hwkO4O1M8tgD35BmYA1sf7sWaLJz/rcGKXHMQb+1jfkZ hyW8GtGAvF/LmoAV88i2di1k9TfMQr+vWJURkYh6YC6vFuW/B36wtQd8FoPZri1xfx5VgBnWXv G5xgY+nI80G6TYN76NNalJTnRHO1SluFUm1axsgGRbfnX2B1e/wRybfIWxkOYFWe+dEXSP3CoG 2sM= X-IronPort-AV: E=Sophos;i="5.68,280,1569312000"; d="scan'208";a="42925297" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 07 Nov 2019 23:59:55 -0800 IronPort-SDR: 3UohMB8bVeMGtKGNts5gnyPwv+koc3i9agDzzLtFOnZjNUsVWEWK0OeqfcipHm8oJt4/taJD6s Rjfveq7G4ftziia7mxeA2RWjqxP3GFfg41S24KSgjuyydde9NW4DDHHJmt+73xxviwOEqmv/5S QhLlCPQDjA5BiqJElNnu3ZI0X0GtfPZjHQh+8v03giu5wuyU0WqAeca9ON8hSeqvZSgWRnxSUT pKtiYZrDdCL2pdUxbU+/E5x8PdeM/m/rHp6KaDBXCjEkdksUCRYsA4yxK86CZjnig1+Pwzh5cV az4= Subject: Re: [PATCH L-C v3 6/7] buildchroot-host: install qemu-static to support hybrid cross-compiles To: Jan Kiszka , References: <1573118604-909-1-git-send-email-Cedric_Hombourger@mentor.com> <1573196839-1143-1-git-send-email-Cedric_Hombourger@mentor.com> <1573196839-1143-7-git-send-email-Cedric_Hombourger@mentor.com> <28a6ef09-18f0-8e82-c464-2d2d530718b2@siemens.com> <84c9fbd7-aef5-2e06-ee38-5e9d44dc609a@mentor.com> <869f9760-f4ed-879f-655f-c03abd34c999@siemens.com> From: Cedric Hombourger Message-ID: Date: Fri, 8 Nov 2019 08:59:47 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <869f9760-f4ed-879f-655f-c03abd34c999@siemens.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Return-Path: Cedric_Hombourger@mentor.com X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4) To svr-ies-mbx-02.mgc.mentorg.com (139.181.222.2) X-TUID: dLGH0eJZKMXg On 11/8/19 8:35 AM, Jan Kiszka wrote: > On 08.11.19 08:22, Cedric Hombourger wrote: >> >> On 11/8/19 8:14 AM, Jan Kiszka wrote: >>> On 08.11.19 08:07, Cedric Hombourger wrote: >>>> The Linux kernel has great support for cross-compiling the kernel >>>> image >>>> and modules. There is however no support/mechanism for >>>> cross-compiling the >>>> build tools from its "scripts" directory. While HOSTCC may be set >>>> to use >>>> our cross-compiler, the kernel build infrasture would then try to run >>>> foreign-arch binaries such as fixdep. The easiest and least >>>> intrusive way >>>> to support this is to enable execution of such binaries via >>>> binfmt/qemu >>>> like we do in the buildchroot-target environment. >>>> >>>> Signed-off-by: Cedric Hombourger >>>> --- >>>>   meta/recipes-devtools/buildchroot/buildchroot-host.bb | 6 ++++++ >>>>   1 file changed, 6 insertions(+) >>>> >>>> diff --git a/meta/recipes-devtools/buildchroot/buildchroot-host.bb >>>> b/meta/recipes-devtools/buildchroot/buildchroot-host.bb >>>> index 408ad39..2e76acb 100644 >>>> --- a/meta/recipes-devtools/buildchroot/buildchroot-host.bb >>>> +++ b/meta/recipes-devtools/buildchroot/buildchroot-host.bb >>>> @@ -15,3 +15,9 @@ BUILDCHROOT_PREINSTALL ?= " \ >>>>       ${BUILDCHROOT_PREINSTALL_COMMON} \ >>>>       libc6:${DISTRO_ARCH} \ >>>>       crossbuild-essential-${DISTRO_ARCH}" >>>> + >>>> +buildchroot_install_files_append() { >>>> +    if [ -e '/usr/bin/qemu-${QEMU_ARCH}-static' ]; then >>>> +       sudo cp '/usr/bin/qemu-${QEMU_ARCH}-static' >>>> '${BUILDCHROOT_DIR}/usr/bin/qemu-${QEMU_ARCH}-static' >>>> +    fi >>>> +} >>>> >>> >>> You didn't address my comment on this one. I doubt it's the right >>> approach. >> >> More specifically? >> >> I do have something in the works but we *still* need to build a >> linux-kernel-headers package for the target. there are two approaches: > > Currently, if you need the package for the target, you need to build > it natively. The cases of requiring such packages is so far rare > enough (none in all the many cases I saw so far) to deal with the > slowdown. > >> (1) use the Makefiles from the kernel and "simply" override HOSTCC >> but you then need qemu-static since the kernel will need to run some >> of its tools from "scripts/" (fixdep in particular) when it builds >> the other tools (e.g modpost) or (2) do like upstream manually >> cross-compile the tools. >> >> The downside of (2) is that you need to know what to compile (list of >> .c files) and how to compile them. That "knowledge" may vary from one >> kernel to another. >> >> I have local patches to produce a linux-kernel-headers-cross-amd64 >> package which will ship headers in /usr/${DEB_HOST_GNU_TYPE} (i.e. >> next to libc headers) as well as kernel build tools for the build >> machine (typically amd64). This will allow us to cross-compile >> out-of-tree kernel modules without running any tools with a >> foreign-arch (for the avoidance of doubt, we still need >> qemu-user-static in buildchroot-host while building the kernel) >> >> So with all that said, you are more than welcome to suggest a better >> approach.... > > Step 1 is to tag the currently generated header package in a way that > it won't be accidentally selected for target installation when it was > cross-built for a different host architecture. Step 2 could be > factoring out the linux-headers package build so that it can run with > ISAR_CROSS_COMPILE = "0" for the target architecture in the target > buildchroot - when that special case is actually needed. If in step1, you are suggesting that our recipe generates packages for the following "Architecture": ${HOST_ARCH}, all, ${DISTRO_ARCH} then to the best of my knowledge that isn't possible! I think you can only generate packages for all, ${DISTRO_ARCH} from a dpkg-buildpackage run but again, let me know if you think otherwise (could not find anything in the Debian Standards document suggesting so but I may have overlooked) If we agree that using debhelper and therefore our generic dpkg class is a good improvement (compared to kernel's builddeb script crafting packages on its own and having to specify dependencies manually), I would suggest we stick with the qemu-user-static approach for now (it is only needed for a fraction of seconds during the build so to me that is a non-issue). As hinted, I am working on a linux-kernel-headers-cross package generation. I am currently considering running build.sh a second time but this time targeting HOST_ARCH and with a control file only carrying that -cross package (it would use the same kernel sources/tree as input) but I'd like to make this a second step since it needs more work and I a genuinely believe that the current solution is something we can live with for now > Alternatively, though more for the long run, the tools cross-build of > upstream could be improved. yes that would be good (if you are referring to the ability to do something like make scripts O=build-host-tools HOST_CROSS_COMPILE=${DEB_HOST_GNU_TYPE}- in the kernel) > > Jan >