This page tracks the individual packages that have problems specific to the Debian armel port. It does not include packages that fail on all archtectures.

When a package will build ok in sid, please remove its entry from here.

arm/armel inconsistencies

The following list covers all packages that

Most are of the form "[long list of arches not including armel]" or "[!arm]".

Please remove when resolved:

The following packages are enabled on arm but not armel and rightly so:

Alignment traps

If you say echo 5 > /proc/cpu/alignment you can make misaligned word and half-word accesses give a Bus Error instead of the default behaviour of silently returning a garbage value (specifically, in the case of a 4-byte word, *(addr & ~3) <<< (addr&3) where <<< is byte-rotate, not bit-shift.

Affected programs:

Languages

clisp

Common Lisp works on arm, binary packages does not include armel in the source package's debian/control Package: sections.

In March 2008, Mat "mexon" made some progress and posted notes and patches for that attempt to port it to Maemo. See the messages to debian-arm and on sourceforge.

Cannot currently be built from source on Debian armel for lack of libffcall1-dev from ffcall.

Dependent packages:

fpc

Free Pascal compiler, a.k.a. fp-compiler. Exists in sid for arm, i386, amd64 and powerpc. Requires itself to compile itself and contains cpu-specific code generators: the arm one may or may not work unmodified on armel. Porting it means cross-compiling it, installing the cross-compiled version and using that to build the package, as well as possibly modifying its code generator for EABI.

An alternative is for dependent packages to move to (or also accept) gpc, the GCC-based pascal compiler (wishlist bugs have been filed where appropriate).

Dependent source packages:

Upstream is working on arm EABI port of freepascal, and has already committed many fixes to svn,

gcc

ARM EABI support was done for gcc-3.4 by CodeSourcery and published as source, but the changes were never backported into the mainline gcc-3.4.

gcc-3.4-dependent source packages:

gcc-3.3-dependent source packages:

gnat

The GNU Ada translator. Requires itself to compile itself. Not provided on ARM old-EABI either.

There are three gnat packages: gnat-4.1, gnat-4.2 and gnat-4.3.

The Ada front-end to GCC is written in Ada (der!) and translates Ada into an internal GCC tree representation, which is then compiled with the usual GCC back-end. It seems we cannot get away with doing the initial translation of the Ada parts on some other machine and transporting that to armel to do the final compilation because header files and even some Ada package specs are system dependent.

Porting appears to require making an x86->ARM gcc/gnat cross-compiler, then if that compiler seems to work on small Ada programs, using that to cross-compile a native ARM Ada compiler, then using that to build the Debian package. This should only need doing for one of the versions to be able to create both Debian packages, modulo any system dependent modifications to header files and package specs.

On the gcc mailing list, Arnaud Charlet says that you need gnat-4.N to build cross-gnat-4.N, which looks like it might triple the already large amount of work required. However, the Debian build dependencies say that all of them will build with gnat>=4.1, so if we can make a cross-version of 4.1 to bootstrap a native compiler, that might work to compile 4.2 and 4.3 natively.

On the gcc list LG recommends starting with trunk (4.3) which is in stage 2 and "should be stable". The maintainer of ghdl, the only package requiring gnat-4.2, says gnat-4.2 is slated for removal anyway.

No Ada binaries site or other operating system distribution that supports ARM (ARMedslack, Maemo, NetBSD, ?OpenEmbedded, Rock Linux) provides precompiled gnat binaries for ARM.

As well as porting gnat-4.X, gcc-defaults will need its Package: gnat enabling for armel.

Dependent source packages:

and [armel] needs adding to the arch list for most of these too.

If gnat is ported, the ada language bindings should be re-enabled for plplot (disabled by 478891).

Interesting sites:

gprolog

Lacks an ARM assembly code generator.

ikvm

Java virtual machine/compiler implemented in .NET (Mono)

Lacks an ARM assembly code generator.

kaffe

A JVM to run Java bytecode, hasn't build on "arm" either.

Version 2:1.1.8-1 failed to build on armel on 4 Oct 2007 and the current version is 2:1.1.8-3, which fails the same way, saying

md.c: In function 'flush_dcache':
md.c:39: error: expected ':' or ')' before '__sys1'
md.c:35: warning: unused parameter 'start'
md.c:35: warning: unused parameter 'end'
make[3]: *** [libkaffe_la-md.lo] Error 1

from /build-tree/kaffe-1.1.8/config/arm/linux/md.c symlinked from build/jthreads/kaffe/kaffevm/md.c, which is:

void flush_dcache(void *start, void *end) {
  __asm __volatile (
...
                    "swi " __sys1(__ARM_NR_cacheflush) "\n" <-- this

In CVS, kaffe has a patch to fix the ARM interpreter by commenting this function out #ifdef TRANSLATOR

and there is discussion of how to fix the __sys1 error on arm old-ABI on the kaffe mailing list, though this doesn't address EABI.

The ARM issues are finally addressed in Jan 2008 on the kaffe mailing list; they now have cacheflush assembler for both old-ABI and EABI, but for EABI there are floating point issues due to its code generator issuing FPA instructions. The whole thread is easier to read here on nabble.

The same EABI system call fix will need propagating to where this code was stolen from in parrot, though Debian doesn't include parrot.

Until a new upstream version of kaffe makes it to Debian, the best we can easily do is build the interpreter and live with the broken floating point.

/usr/bin/make  check-TESTS
PASS: HelloWorldApp.class.save
FAIL: HelloWorldApp.java
FAIL: MultiArray.java
FAIL: RefTest.java
FAIL: TestIntLong.java
PASS: TestFloatDouble.java
FAIL: DoubleCvt.java
FAIL: DoubleNeg.java
FAIL: DoubleConst.java
FAIL: DoublePrint.java
FAIL: DoubleComp.java
FAIL: ModuloTest.java
FAIL: LongNeg.java
FAIL: FPUStack.java
...
135 of 150 tests failed

Libraries

dietlibc

Needs upstream support for ARM EABI, see 459482.

A tiny change (removing -mhard-float in arm/Makefile.add) lets the current version from SVN build on armel but the first test fails saying

/usr/lib/gcc/arm-linux-gnueabi/4.2.3/libgcc.a(_divdi3.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'

It may be possible to make the existing "arm" build structure work on armel without inventing a whole new port by using #ifdef __ARM_EABI__ in the assembler fragments, but it requires at least:

and an unknown number of other things.

Interestingly, most architectures only support static linking with dietlibc (binary package "dietlibc-dev"); dynamic linking is said to work on i386 and arm, but the dynamic-link binary package ("dietlibc") is only built for i386.

Dependent source packages:

The following packages would like dietlibc, but can manage without it. If it is ported, they would like to have [armel] added to their Build-Depends: dietlibc-dev architecture lists:

ffcall

Foreign Function Call Libraries

Build of 1.10+2.41-3 fails on armel saying

gcc -x none -c vacall-arm.s
vacall-arm.s: Assembler messages:
vacall-arm.s:3: Warning: ignoring attempt to redefine built-in register 'sl'
vacall-arm.s:4: Warning: ignoring attempt to redefine built-in register 'fp'
vacall-arm.s:5: Warning: ignoring attempt to redefine built-in register 'ip'
vacall-arm.s:6: Warning: ignoring attempt to redefine built-in register 'sp'
vacall-arm.s:7: Warning: ignoring attempt to redefine built-in register 'lr'
vacall-arm.s:8: Warning: ignoring attempt to redefine built-in register 'pc'
vacall-arm.s:80: Error: selected processor does not support `ldfeqs f0,[sp,#20]'
vacall-arm.s:84: Error: selected processor does not support `ldfeqd f0,[sp,#20]'
make[2]: *** [vacall-arm.o] Error 1

ldfeqs and ldfeqd appear to be old arm FPA instructions, which either need replacing or reconfiguring to use softfloat. NetBSD and Clisp people have encountered the same problem without solving it yet, though Mat's clisp notes make considerable progress on it.

Dependent source packages (on libffcall1-dev):

haskell-happs-*

Haskell libraries for building Internet applications

The old "happs" source package has now split into five: haskell-happs-{data,ixset,server,state,util} 

Of which -util is marked for Architecture: i386, amd64 and the rest are for any but Build-Depend on haskell-happs-util-dev. This may be a legacy of 443053, an old bug.

haskell-happs-utils build fails if enabled on armel, saying:

Preprocessing library HAppS-Util-0.9.2.1...
Building HAppS-Util-0.9.2.1...

src/HAppS/Util/TH.hs:4:7:
    Could not find module `Language.Haskell.TH':
      Use -v to see a list of the files searched for.
make: *** [build-ghc6-stamp] Error 1

lapack3

Exists for arm and armel, but installing it on either evokes a big fat warning:

 x Critical lapack errors                                                    x
 x                                                                           x
 x One or more critical lapack library errors were discovered when this      x
 x package was built.  As of the time of this writing, all known such        x
 x errors are due to compiler and/or ld.so errors on the affected            x
 x architectures.  The lapack libraries in this set of packages then, while  x
 x practically useless for serious numerical research, are provided here     x
 x nonetheless to facilitate smooth upgrades of lapack into Debian as a      x
 x whole.

libffi

The package is built and included in the repository, but the testsuite fails on 8 tests:

Running /home/martin/arm/libffi-3.0.4/testsuite/libffi.special/special.exp ...
FAIL: libffi.special/unwindtest.cc  -shared-libgcc -lstdc++ (test for excess errors)
FAIL: libffi.special/unwindtest_ffi_call.cc  -shared-libgcc -lstdc++ (test for excess errors)
FAIL: libffi.special/unwindtest.cc  -shared-libgcc -lstdc++ (test for excess errors)
FAIL: libffi.special/unwindtest_ffi_call.cc  -shared-libgcc -lstdc++ (test for excess errors)
FAIL: libffi.special/unwindtest.cc  -shared-libgcc -lstdc++ (test for excess errors)
FAIL: libffi.special/unwindtest_ffi_call.cc  -shared-libgcc -lstdc++ (test for excess errors)
FAIL: libffi.special/unwindtest.cc  -shared-libgcc -lstdc++ (test for excess errors)
FAIL: libffi.special/unwindtest_ffi_call.cc  -shared-libgcc -lstdc++ (test for excess errors)

libvorbis

The libvorbisenc component is buggy on armel; it almost always produces short output files that contain a correct Ogg encoding of the correct length of silence. There's a Debian bug report (515949) but, as it affects all ARM EABI systems, it has gone upstream.

This means that oggenc and anything producing vorbis-encoded audio is broken; the decoder is fine.

lua-gtk

gtk bindings for the lua language version 5.1

Unlike every other liblua5.1-* package, lua-gtk is only enabled for i386 and amd64.

Enabling it for armel here, much of the testsuite fails, spewing Bus errors (indicative of misaligned 32-bit word data accesses).

497172. Closed but not fixed really, and an armel build dies with misaligned data acceses.

openmpi

Library for parallel applications has not been explicitly ported to ARMs, but is believed to work on most 32-bit Unices. On armel the configure dies saying:

configure: error: No atomic primitives available for arm-unknown-linux-gnueabi

Most Debian packages can use mpich instead, which is available on armel.

This source packages would build more completely if openmpi were available:

These would use it if it were available:

openmpi is not included in lenny.

petsc

Parallel scientific library

This builds in two flavours:

The lam version does not produce libpetsc2.3.3-dev, which is required by:

purelibc

A system call virtualizing library, part of the View-OS project needs trivial patches to compile on armel to eliminate obsolete and unsupported system calls.

This package is new in lenny, and appears to need some general portability help.

uclibc

Has disappeared completely from Debian.

System components

adeos

"nanokernel for sharing hardware resources among multiple operating systems, or among multiple instances of a single OS" consists of a kernel patch which is available on arm, i386, ia64, powerpc and ppc64. Its binary consists of a kernel patch which may or may not need hacking for EABI.

cacao

Virtual machine for running Java programs.

Did not make it into lenny but is built for armel in squeeze.

nsis

Nullsoft Scriptable Install System. Version 2.31-1 failed to build on armel 4 Oct 2007, dying at the very last moment, saying

Generating uninstaller...
Error finding icon resources: installer, uninstaller icon size mismatch - see the Icon instruction's documentation for more information -- failing!

Current version is 2.37-2, and it has only succeeded on i386 and amd64.

vnc4

Virtual network computing software fails to build saying:

make[6]: Leaving directory `/build/buildd/vnc4-4.1.1+X4.3.0/unix/xc/programs/Xserver/hw/vfb'
[...]
c++ -o XFree86 -O3 -fsigned-char     -L../../exports/lib  -L/usr/X11R6/lib xkb/xf86KillSrv.o xkb/xf86VT.o xkb/xf86Private.o        ../../programs/Xserver/hw/xfree86/common/xf86Init.o ../../programs/Xserver/hw/xfree86/common/xf86IniExt.o ../../programs/Xserver/hw/xfree86/common/libxf86.a             ../../programs/Xserver/hw/xfree86/parser/libxf86config.a ../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a ../../programs/Xserver/hw/xfree86/loader/libloader.a              ../../programs/Xserver/hw/xfree86/common/libxf86.a dix/libdix.a os/libos.a ../../exports/lib/libXau.a ../../exports/lib/libXdmcp.a            ../../lib/font/fontbase.o                  ../../lib/font/libfontbase.a Xext/libexts.a xkb/libxkb.a Xi/libxinput.a                   lbx/liblbx.a                   ../../lib/lbxutil/liblbxutil.a vnc/libvnc.a ../../../../common/rfb/librfb.a                    ../../../../common/Xregion/libXregion.a                    ../../../../common/network/libnetwork.a                    ../../../../common/rdr/librdr.a ../../programs/Xserver/hw/xfree86/common/libxf86.a             Xext/libexts.a xkb/libxkb.a Xi/libxinput.a                   lbx/liblbx.a                   ../../lib/lbxutil/liblbxutil.a vnc/libvnc.a ../../../../common/rfb/librfb.a                    ../../../../common/Xregion/libXregion.a                    ../../../../common/network/libnetwork.a                    ../../../../common/rdr/librdr.a randr/librandr.a render/librender.a dix/libxpstubs.a mi/libmi.a Xext/libexts.a xkb/libxkb.a Xi/libxinput.a                   lbx/liblbx.a                   ../../lib/lbxutil/liblbxutil.a vnc/libvnc.a ../../../../common/rfb/librfb.a                    ../../../../common/Xregion/libXregion.a                    ../../../../common/network/libnetwork.a                    ../../../../common/rdr/librdr.a randr/librandr.a render/librender.a  ../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a     -lz -lm                 -rdynamic -ldl  -Wl,-rpath-link,../../exports/lib
c++: ../../programs/Xserver/hw/xfree86/loader/libloader.a: No such file or directory
make[5]: *** [XFree86] Error 1
make[5]: Target `all' not remade because of errors.

It succeeds on other architectures but not on "arm", with the same error.

Applications

iceape-browser

Web browser also known as mozilla-browser

Version 1.1.11-1 is in the repository but, when run, loops forever consuming 100% CPU.

ktoon

2D animation toolkit

Version 0.8.1-1 failed on armel on 25 Sep 2007 saying

ktprojectparser.cpp:215: error: no match for 'operator<<' in '((KTProjectParser*)this)->KTProjectParser::m_gradientStops [...]

The current version is 0.8.1-4 and fails thus on arm and armel.

qemu

440425 fixed upstream, armel package now in experimental.

varkon

CAD system. Needs gcc-3.3 to build because of -fwritable-strings in Makefiles. The latest upstream version removes this need 453009. Debian packages of the new version are now available but it is currently orphaned and needs a Debian sponsor for it to upload.