Re: Cross-building Debian `linux` package (Was: Re: Unmet dependencies problem in CrossToolchains)
(Oops, sorry for the personal reply, Shawn; here's a copy for the list)
On 04/06/2015 09:17 PM, Shawn Landden wrote:
> On Mon, Apr 6, 2015 at 6:53 PM, John Morris <john@zultron.com> wrote:
>>
>>
>> On 04/06/2015 05:22 PM, Shawn Landden wrote:
>>>
>>> On Mon, Apr 6, 2015 at 3:15 PM, John Morris <john@zultron.com> wrote:
>>>>
>>>>
>>>>
>>>> On 03/30/2015 10:45 PM, Wookey wrote:
>>>>>
>>>>>
>>>>> +++ John Morris [2015-03-30 22:16 -0500]:
>>>>>
>>>>>> I'm going to try setting up Wookey's cross-build daemon
>>>>>
>>>>>
>>>>>
>>>>> (careful - it really could do with some more work to be moderately
>>>>> general!)
>>>>>
>>>>>> or use sbuild directly, so never mind.
>>>>
>>>>
>>>>
>>>> Thanks for the tips, Wookey. I ended up adding `sbuild`
functionality to
>>>> some scripts I had laying about, and it looks like all the Machinekit
>>>> dependencies can be compiled.
>>>>
>>>> However, there are a few packages that can't be *cross*-compiled, the
>>>> most
>>>> irritating of which is the Debian `linux` package. (I've modified the
>>>> packaging to build Xenomai and RTAI 'featuresets'.)
>>>>
>>>> The problem is the explicit `Build-Depends: gcc-4.9`, which can't
be met
>>>> by
>>>> the `crossbuild-essential-armhf` or its dependencies. For now
qemu will
>>>> get
>>>> the job done, but of course take ages to do it.
>>>>
>>> What are you building linux for? If it is just the linux-libc-dev
>>> package then there might be a reduced build that only builds that.
>>
>>
>> Xenomai [1] and RTAI [2] are two real-time frameworks. They're both
based
>> on the ipipe patch, which is a heavy modification to the Linux kernel.
>> Looks like I may have to start building the RT_PREEMPT kernel too, since
>> that's been dropped from Jessie. Machinekit [3] features a RT
threads layer
>> that we've ported to several threads systems.
>>
>> The Beaglebone kernel took over 2 hours to compile with -j8 under qemu.
>> Ouch.
> Just skip the debian packaging altogether and use `make deb-pkg` from
> the linux source tree. (with CONFIG_CROSS_COMPILE set appropriately)
I've tried pretty much everything under the Debian/Ubuntu/Red Hat suns,
but never really looked at that one. I've heard of folks using that for
one-off kernel builds. From a package distribution perspective, what do
you see as the pros and cons?
A couple of years ago I finally settled on the Debian packaging
(modified with some hooks'n'stuff to be more
featureset/patchset-friendly), and along with it the whole
`linux-tools`/`linux-latest` etc. kernel package infrastructure. In
return, we get things like building multiple kernels (multiple arches +
distros + featuresets) from a single source, a known .config with
differences clearly delineated in override files, a simple and standard
way to declare kernel deps in our kernel thread flavor and userland
thread flavor packages, a working system for out-of-tree kmodule builds,
easy-ish upgrades for new Xenomai/RTAI/Linux releases, and other stuff.
And hey, if it's good enough for the big Debian distribution, it's
good enough for our tiny distribution too, right?
In this particular case, we hope that the Debian package cross-compiles,
or will someday, and when it does, we'll get that benefit, too. And
this takes us back to the original question:
Does anyone know if the upstream Debian kernel package can be
cross-built? I suspect the answer is 'no', because of it
`Build-Depends: gcc-4.9` and I don't see anywhere the Emdebian toolchain
`Provides:` that.
In the case of 'no', does anyone know how this is typically dealt with
when converting packages to Multiarch? If it's atypical for packages to
configure a specific gcc version, I can hack something, but if there's a
standard approach, maybe I can try something that can be contributed back.
Thanks-
John
Reply to: