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

[Alexander Smirnov <asmirnov@ilbers.de>]

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.

Alex

>
> Jan
>
> --
> You received this message because you are subscribed to the Google Groups 
> "isar-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to isar-users+unsubscribe@googlegroups.com.
> To post to this group, send email to isar-users@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/isar-users/1ed1ad84-acaf-1aa9-0ac7-f2f1353670ab%40siemens.com.
> For more options, visit https://groups.google.com/d/optout.