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

[Alexander Smirnov <asmirnov@ilbers.de>]

On 07/18/2018 10:06 AM, Jan Kiszka wrote:
> 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.
> 

Just an observation, you use here buster but I didn't test it.

Alex