Re: [PATCH v3 0/7] Isar cross-compilation support

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2018-07-17 22:48, Alexander Smirnov wrote:
> 
> Jan Kiszka <jan.kiszka@siemens.com> 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 := ?
> 
>>
>> | 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...
>>
>>
>> And then python - I'm still facing that issue with another package as
>> well:
>>
>> | Setting up python2.7-minimal:arm64 (2.7.13-2+deb9u2) ...
>> | /var/lib/dpkg/info/python2.7-minimal.postinst: 42:
>> /var/lib/dpkg/info/python2.7-minimal.postinst: python2.7: not found
>> | dpkg: error processing package python2.7-minimal:arm64 (--configure):
>> |  subprocess installed post-installation script returned error exit
>> status 127
>> | dpkg: dependency problems prevent configuration of
>> python-minimal:arm64:
>> |  python-minimal:arm64 depends on python2.7-minimal (>= 2.7.13-1~);
>> however:
>> |   Package python2.7-minimal:arm64 is not configured yet.
>> |
>> | dpkg: error processing package python-minimal:arm64 (--configure):
>> |  dependency problems - leaving unconfigured
>> | Errors were encountered while processing:
>> |  python2.7-minimal:arm64
>> |  python-minimal:arm64
>> | E: Sub-process /usr/bin/dpkg returned an error code (1)
>>
>> Corresponding build dependencies there:
>> Build-Depends: wget, cpio, unzip, rsync, python, bc
>>
>> Here I get my job done by hacking it this way:
>> Build-Depends: wget, cpio, unzip, rsync, python:amd64, bc
> 
> Is it possible to reproduce these results on my machine? I.e. are these
> artifacts available in public? In my series I only guarantee that isar
> tree is buildable, but unfortunately it doesn't cover all the possible
> cases. :-( As mention above, we definetely need to add ARM kernel
> configs to meta-isar to test real cross-compilation out of the box.

Sure: I'm testing with https://github.com/siemens/jailhouse-images,
current next branch. You may skip the length non-root-initramfs package
and also just do the Orange Pi Zero build.

We can also switch to the CIP kernel in Isar for the Banana Pi target.
Will notably prolong the CI run, though.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux