From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6579174846558633984 X-Received: by 2002:a19:db5b:: with SMTP id s88-v6mr253725lfg.30.1531903065011; Wed, 18 Jul 2018 01:37:45 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:7605:: with SMTP id r5-v6ls418990ljc.13.gmail; Wed, 18 Jul 2018 01:37:44 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfUqOmKXGft4wNJMNjyaiyI0cFeIzIDPfAX/6q9YcQkuMZkrqOw3oCnFiy1BdILpUMlptu0 X-Received: by 2002:a2e:2c10:: with SMTP id s16-v6mr311518ljs.8.1531903064424; Wed, 18 Jul 2018 01:37:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531903064; cv=none; d=google.com; s=arc-20160816; b=WjtIzviLj+pTaLz2Wz6+edOkKX3AxeTMMUBmf+CkVH3/vbkmePxtxwi6vJGUQzKBKm XFwAwcDv+HzdqwPHyt+cxw7FCwUZ9P2HJeXPcjZbYxNdsy3gFVjugdi8VgUADGIVagHe uSkRwg0fy9QRlEF7eqcHId0L3HCt1bDZlcbugs+8A2qSH2bUJY15HQqPlnalF80JoKw4 PcmUy8mGARsMfwzhKtX/lHN6e6v61fCbL755SuYt+AZSw1X7GG9ZIUkISgZ6tEKDFEVC QUswCOBcCMyIBZtyK8iOEjn2VuGw3Mo/pKkZJwU6kcitsP9B4qi9b+O9S+bg7M0eUzFO Jtng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:references:to:from:subject :arc-authentication-results; bh=Wo11doX46iZ4QOCjtu/Mxzypn/T9BIJUwx4Xb77ETso=; b=zlVsoKXszyfFddgGhPZs9IWL1S1bzQd/+ES1X2okrA2wZFm/0g7OQbOYJklSpFjjNX i3iOHzyPqe3ZL3BtEKK3lspMqywODZVEob+B883TfM6wkzG0PtbyNHgphiKKzAOs/3Ts gt7VYCYxCDMuSAr0R15qtfn5XB/8mYd/l4axCe+YbV96977lOg6ZWnAxt0Hj9n1Soh78 cHrNSFXW18KPtTY45twipWDV/dK2NnwMJRAp08vjZJGY3jJN7TFHf46rtyloPkoID6ig H7bGLpbt8ZLGWHsGBaiJeRYuQbBEtmnaS8lacnDTW1vCf3ZVXE+d+tzvvRIP6SRSBI85 rc3Q== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id 77-v6si100829lfs.5.2018.07.18.01.37.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jul 2018 01:37:44 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w6I8bhN2027635 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 18 Jul 2018 10:37:43 +0200 Received: from [139.22.160.78] ([139.22.160.78]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id w6I8bh99002742; Wed, 18 Jul 2018 10:37:43 +0200 Subject: Re: [PATCH v3 0/7] Isar cross-compilation support From: Jan Kiszka To: Alexander Smirnov , isar-users@googlegroups.com References: <20180717131811.14239-1-asmirnov@ilbers.de> <5c45490f-9dce-b43a-14b3-8347931c40ef@siemens.com> <507beff8-3503-22a9-c3f6-0a01f3f7a132@ilbers.de> <1ed1ad84-acaf-1aa9-0ac7-f2f1353670ab@siemens.com> <164aa001af8.27ac.034a6b0541ed39b7fb4e17f4ac219eaa@ilbers.de> Message-ID: <31b2b3a9-48d5-812a-20b1-d3f05bf0bc1f@siemens.com> Date: Wed, 18 Jul 2018 10:37:42 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: V1tKAiKnQCZ+ On 2018-07-18 10:19, Jan Kiszka wrote: > On 2018-07-18 09:06, Jan Kiszka wrote: >> On 2018-07-17 22:48, Alexander Smirnov wrote: >>> >>> Jan Kiszka 17 июля 2018 г. 22:45:11 написал: >>> >>>> On 2018-07-17 17:41, Alexander Smirnov wrote: >>>>> >>>>> >>>>> On 07/17/2018 04:38 PM, Jan Kiszka wrote: >>>>>> On 2018-07-17 15:18, Alexander Smirnov wrote: >>>>>>> Hi everybody, >>>>>>> >>>>>>> sorry for the delay, this is the third version of cross-compilation >>>>>>> support for Isar. >>>>>> >>>>>> Thanks for the update! >>>>>> >>>>>>> Supported targets for cross-compilation: >>>>>>>  - stretch armhf >>>>>>>  - stretch amd64 >>>>>>> >>>>>>> Artifacts could be cross-compiled: >>>>>>>  - dpkg.bbclass users >>>>>>>  - dpkg-raw.bbclass users >>>>>>>  - kernel >>>>>>> >>>>>>> Known issues: >>>>>>>  - if target and host architectures are the same, there is no need >>>>>>>    to use host buildchroot. >>>>>>>  - kernel module doesn't support cross-compilation. Default >>>>>>> linux-headers >>>>>>>    package depends from target gcc binaries. So attempt to install, >>>>>>> for >>>>>>>    example linux-headers-armmp, tries to install gcc:armhf, what rises >>>>>>>    conflict with the host tools. >>>>>> >>>>>> Could you imagine overriding such specialties with extra rules, even if >>>>>> package specific? Not having kernel module in the cross compilation >>>>>> chain main cause troubles (or does it work fine to cross-build the >>>>>> kernel and then natively build the modules?). >>>>> >>>>> What I'd like to try: >>>>> 1. Add ARM defconfig for linux-cip >>>>> 2. Try to build example module for linux-cip for armhf >>>>> >>>>> Regarding overriding default Debian kernel, ATM I don't see any >>>>> possibilities. Just as an exercise - I tried to install >>>>> linux-headers-armmp: >>>>> >>>>> $ sudo dpkg --add-architecture armhf >>>>> $ sudo apt-get update >>>>> $ sudo apt-get install linux-headers-armmp >>>>> >>>>> No chances here, this package pulls lots of armhf binaries that conflict >>>>> with the host ones. The only way I see now is to manually fetch and >>>>> unpack this package. But it's an ugly hack IMHO :-( >>>> >>>> But maybe we can resolve that issue for self-built kernel by providing >>>> also a compatible headers package? >>> >>> >>> I need to investigate this topic in more details. >>> >>>> >>>> >>>>> >>>>> Regarding hybrid mode (apps and kernel are compiled cross, modules are >>>>> compiled natively) - this works. You could check this by trying >>>>> cross-build for qemuarm-stretch, for example. >>>> >>>> I suppose to opt-out a package from cross-building, I need to add >>>> ISAR_CROSS_COMPILE = "0" to its recipe, right? Currently trying... no: >>> >>> Hmm, actually it should. That's how I disable cross-comp for kernel >>> modules. Could you try more strength assignment := ? >>> > > Sorry, "no" was referring to the build in general. I can enforce the > opt-out via ISAR_CROSS_COMPILE = "0" successfully. > >>>> >>>> | Broken jailhouse-build-deps:arm64 Depends on >>>> linux-headers-jailhouse-arm64:arm64 < none @un H > >>>> |   Removing jailhouse-build-deps:arm64 because I can't find >>>> linux-headers-jailhouse-arm64:arm64 >>>> >>>> The problem seems to be that the header package is generate as :amd64, >>>> so I can't install it into the arm64 buildchroot. However, the cross >>>> build also fails because it searches for :arm64 as well: >>>> >>>> | Broken jailhouse-cross-build-deps:arm64 Depends on >>>> linux-headers-jailhouse-arm64:arm64 < none @un H > >>>> |   Removing jailhouse-cross-build-deps:arm64 because I can't find >>>> linux-headers-jailhouse-arm64:arm64 >>>> >>>> By requesting :amd64 versions of the header as well as some python deps, >>>> I'm getting further and then fail differently: >>>> >>>> | dpkg-architecture: warning: specified GNU system type >>>> aarch64-linux-gnu does not match CC system type x86_64-linux-gnu, try >>>> setting a correct CC environment variable >>>> |  dpkg-source --before-build git >>>> | dpkg-buildpackage: info: host architecture arm64 >>>> | dpkg-checkbuilddeps: error: Unmet build dependencies: python-pip:amd64 >>>> python-setuptools:amd64 python-mako:amd64 >>>> >>>> "host architecture arm64", that is suspicious... >>>> > > I'm starting to wonder if there is the wrong architecture set at some > level, which may also explain why dpdk pulls tool packages for the > target architecture, rather than the host arch. Does that ring any bell? > Again looking at that wiki, I'm seeing CONFIG_SITE=/etc/dpkg-cross/cross-config. \ DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -aarmhf as the recommended invocation pattern for dpkg-buildpackage. Our build.sh does not seem to set those to variables, neither for the build nor the separately run mk-build-deps. Intentionally? Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux