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

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

On 2018-07-18 09:06, 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 := ?
>>

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?

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