Re: Embedded and ARM Debian Sprint
On Sun, Nov 7, 2010 at 2:24 PM, Tzafrir Cohen <firstname.lastname@example.org> wrote:
> On Sun, Nov 07, 2010 at 02:04:21PM +0000, Luke Kenneth Casson Leighton wrote:
>> there's a low-cost embedded x86 processor by RDC which ... hum... it
>> can't run qt4 apps because the f*****g qt4 low-level image blit
>> library assumes MMX instructions by default. and... 486 .debs were
>> dropped several years ago, weren't they? so you get 386 .debs and
>> they don't f****g work.
> /usr/lib/mmx (or whatever it should be)?
apt-cache show libqtcore4:
Depends: libc6 (>= 2.9), libgcc1 (>= 1:4.1.1), libglib2.0-0 (>=
2.12.0), libstdc++6 (>= 4.1.1), zlib1g (>= 1:1.1.4)
so, sadly, qt4 isn't that bright.
but.. you've just raised a good example: why should "standard" qt4 or
any other package be FORCED to link with /usr/lib/mmx when it is just
something that's needed for one specific platform?
by extending debian/control and debian/rules to have
capabilities-specific dependencies and build options
(Depends-arm-NEON: ....) or Depends: libmmx (>= 0.12345,
capability-arm-neon) you'd have all bases covered.
btw - just so people know: i am NOT using debian for the projects i'm
involved with at the moment, precisely because there are going to be
so many different ARM CPU variants in the project. i'd have to be off
my f*****g head to use emdebian, when openembedded has so much
pre-existing recipes for different types of ARM CPUs that can just be
copied and used to get the absolute maximum out of the processor.
if debian had that capability, to just configure one config file
specifying the CPU type then sit back and wait for a couple of days
for the whole toolchain to be downloaded and compiled, and then the
entire OS downloaded and compiled, i'd use it immediately.