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

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

On 2018-07-18 20:52, Alexander Smirnov wrote:
> 
> 
> 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.

Yes, but only for the pre-built u-boot package, and only for the Orange
Pi. See conf/multiconfig/preferences.orangepi-zero.conf.

Jan

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