Re: ARM Ports BoF: armel in buster
On 08/28/2017 10:23 AM, W. Martin Borgert wrote:
> Quoting uhmgawa <uhmgawa@member.fsf.org>:
>> On 08/28/2017 08:46 AM, W. Martin Borgert wrote:
>>> As long as you have enough flash memory (some hundreds of MiB) and RAM
>>> (at least 64 MiB, better 128 MiB), Debian runs fine on such hardware
>>> in my experience. It depends on your applications, of course.
>>
>> Available flash is from 32~64MB depending on platform. So manual subset
>> of the distro id required and where recurring the effort enters the picture.
>
> OK, then Debian is probably not an option. I doubt, that one can strip down
> Debian 9 to 32 MiB... Has anybody tried?
We've done so for Jessie, but it is a rather tedious manual process and one which
starts eroding the benefit of project soak on a supported installation footprint.
A relief I didn't call out previously is these figures are physical sizes. We can shoe
horn in considerably more using squashfs, resulting in an acceptable image for
even 24MB flash.
>
>>> Debian is supposed to be the "universal operating system". I.e. it is for
>>> server + workstation + embedded + whatever. This is different from most
>>> other Linux distributions.
>>
>> I applaud that goal. But the approach of using a native arch build vehicle
>> for the distro also introduces complication for embedded class development.
>> Not insurmountable but additional compared to the cross-build approach
>> typical of embedded linux distros.
>
> The native build requirement is only affecting Debian itself, not its users
> (people deriving the distribution for their needs or building appliances).
> In my company, we always cross-build our .deb packages for ARM. We do this
> also, if we need to recompile official Debian packages (local backports or
> patched packages). We don't have any armel hardware, that would be fun to
> build packages with.
Is cross build generally supported for Debian? My impression was that it was
not and a native arch build vehicle was requires such that host == target. If
cross builds were actively supported by the project for even a subset of distro
content, that would have simplified matters in our case.
Another rub mixing a native-built distro and cross built application is the toolchain
which must be generated from the same source for both native and cross versions.
At least doing so sidesteps a number of issues including agreement of dynamic
library content between the native/cross toolchains such that mixing the distro
and application bits happens under effectively the same runtime libraries.
Reply to: