Differences between revisions 278 and 279
Revision 278 as of 2008-05-01 16:20:21
Size: 48751
Editor: MartinGuy
Comment: add lists of packages with outdated arm* gcj* build-dep exclusions
Revision 279 as of 2008-05-01 16:47:06
Size: 48836
Editor: MartinGuy
Comment: Add bug filed to exclude gnat bindings for plplot
Deletions are marked like this. Additions are marked like this.
Line 318: Line 318:
 * plplot  * plplot (only needed for extra language bindings: [http://bugs.debian.org/478891 bug] filed)

This page tracks the individual packages that have problems specific to the [http://wiki.debian.org/ArmEabiPort 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.

About 90% of the repo is built for armel. The bulk of the remaining packages either:

  • Require gcc-3.4 or earlier, for which EABI support was never backported
  • Require g77, which was replaced in gcc-4 with the separate gfortran
  • Have problems of their own, such as lacking configs for ARM EABI or having bugs that only trigger on EABI
  • Depend on something blocked by the above

?TableOfContents

arm/armel inconsistencies

The following list covers all packages that

  • build-depend/conflict with something on arm, but not on armel, or
  • have the source package listed for Architecture: arm but not armel, or
  • have binary packages disabled on armel in debian/control.

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:

  • catsboot: "Boot glue for ARM CATS systems", which are based on the StrongARM110 CPU, an armv4 chip not supported by armel, which requires armv4t.
  • gcc-4.0 (EABI support entered gcc in version 4.1)
  • gnat-gdb (gnat has not been ported to armel yet. Or to arm, for that matter!)
  • linux-kernel-di-arm-2.6, linux-modules-di-arm-2.6: Corresponding -di-armel-2.6 debian installer packages are not in the unstable source repository yet
  • nwutil: Hardware utilities for ?NetWinder hardware, based on the StrongARM SA-110, which is armv4 and hence not supported in armel.

Linux kernel

Riku Voipio says in [http://lists.debian.org/debian-arm/2008/04/msg00079.html a message to the debian-arm mailing list] 18 April 2008:

The current debian/arm and armel kernels suffer from a bug that deadlocks kernel under certain robust futex operations. This has caused buildd's lock under apr and glibc testsuits. Another issue is that oldabi arm chroots do not work when using a armel kernel.

Fixes for both will be included in next kernel packages uploaded, which should happen really soon now.

Languages

?Anchor(bigloo)

bigloo

"Scheme system which includes a compiler generating C, java, or .NET code, and an interpreter" builds ok with package bigloo-backend-jvm not enabled for armel in debian/control. It should be ok bcos we have gcj and sablevm.

Enabling it, the build fails saying

...
   bdb library installation: yes
   java: no
*** ERROR:configure:Can't configure Java.
Command:
./autoconf/javatest --java=/usr/bin/java --jflags= --jvflags=-noverify --javac=/
usr/bin/javac --jcflags=-O --user=martin --tmp=/tmp --cpsep=":"
failed unexpectedly (see configure.log for details).

To give up with the JVM backend, use:
  ./configure --jvm=no
make: *** [stampdir/configure] Error 3

javatest says:

~/bigloo-2.8c/build-tree/bigloo2.8c$ cat configure.log:
Java compilation command [/usr/bin/javac -O jtest.java >/dev/null 2> /dev/null]
failed

and javac is saying:

~/bigloo-2.8c/build-tree/bigloo2.8c$ /usr/bin/javac -O jtest.java
----------
1. ERROR in jtest.java (at line 1)
        class jtest {
        ^
The type java.lang.Object cannot be resolved. It is indirectly referenced from
required .class files
----------
2. ERROR in jtest.java (at line 1)
        class jtest {
        ^
The type java.lang.String cannot be resolved. It is indirectly referenced from
required .class files
...

Is the armel java compiler working?

?Anchor(clisp)

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 [http://mat.exon.name/logs/clisp notes and patches] for that attempt to port it to Maemo. See the messages [http://lists.debian.org/debian-arm/2008/03/msg00028.html to debian-arm] and [http://sourceforge.net/mailarchive/message.php?msg_name=47CE67C6.4000002%40yahoo.com.au on sourceforge].

Cannot currently be built from source on Debian armel for lack of libffcall1-dev from [http://wiki.debian.org/ArmEabiProblems#ffcall ffcall].

Dependent packages:

  • mcvs
  • xindy

?Anchor(drscheme)

drscheme

Educational Scheme interpereter available on [alpha amd64 hppa i386 mips mipsel powerpc sparc]

It creates two binary packages: drscheme (the user interface) and mzscheme (the language engine). drscheme is enabled for arm, armel, armeb but it run-depends on mzscheme, which is not enabled for it (der!)

Building it on armel provokes a compiler error:

cc -g -Wall -fPIC -DMZ_USES_SHARED_LIB -I./../mzscheme -I.../drscheme-372/src/foreign/../mzscheme/include -I.../drscheme-372/src/foreign/../mzscheme/src -Igcc/libffi/include -c .../drscheme-372/src/foreign/foreign.c  -fPIC -DPIC -o .libs/foreign.o
.../drscheme-372/src/foreign/foreign.c:2467: error: expected specifier-qualifier-list before 'ffi_closure'

because the type ffi_closure is only defined in build/foreign/gcc/libffi/include/ffi.h (autogenerated from src/foreign/gcc/libffi/include/ffi.h.in) #if FFI_CLOSURES is defined and src/foreign/gcc/libffi/src/arm/ffitarget.h has #define FFI_CLOSURES 0

[http://bugs.plt-scheme.org/query/?debug=&database=default&cmd=view+audit-trail&cmd=view&pr=all%2F9281 Query] submitted to [http://bugs.plt-scheme.org/ the drscheme bug tracker].

Dependent packages:

  • minlog

?Anchor(fpc)

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:

Dependent binary packages not enabled on armel: libhdate-pascal.

?Anchor(gcc)

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:

Binaries compiled using -fstack-protector segfault on both arm and armel. The security team has not yet started their big push for using crazy security options everywhere, so this affects only relatively few packages. PR35965, [http://bugs.debian.org/469517 #469517] filed.

Since the migration to gcc-4.3, some source files compiled with -funroll-loops will cause a gcc ICE. This one is affecting surprisingly many packages. PR35964, [http://bugs.debian.org/476460 #476460] filed.

?Anchor(gcj)

gcj

GNU Java Compiler: gcj-4.2 and gcj-4.3 are included in sid.

David Daney writes [http://sourceware.org/ml/crossgcc/2008-03/msg00017.html on the crossgcc list]: "ARM support for gcj only works in GCC-4.3 and later (and then only for the linuxeabi ABI)."

The following packages have had gcj [!armel] added to their Build-Depends: lines, which presumably now needs reversing:

  • gdb [!armel]
  • libtool [!arm]
  • swig1.3 [!armeb !armel]

Likewise, others have had gcj-java-compat [!armel] added, which can now be reversed:

  • brltty [!arm]
  • db [!arm !armeb !armel]
  • db4.5 [!arm !armeb !armel]
  • plplot [!arm]
  • sqlrelay [!arm]
  • subversion [!arm]

?Anchor(g77)

g77

G77, the GNU Fortran 77 compiler, was not continued past gcc-3.4. From gcc-4, there is a separate "gfortran" program.

Missing binary packages are g77, libg2c0 and libg2c0-dev.

Colin Tuckley is tackling the fortran issues and says:

In most packages and quite a few simple libraries the only change is
replacing g77 with gfortran in the Makefile. Unfortunately the way some
things are done and in particular some floating point stuff the
implementation is different enough to cause problems. Not difficult to solve
problems, but things that need looking at and fixing.

Dependent source packages, and source packages that in turn depend on those:

  • arpack
  • arpack++
  • atlas3 (has never been available on arm: lapack3 or refblas3 are the usual alternatives)
  • blacs-mpi
  • blacs-pvm
  • blitz++
  • cernlib
    • mclibs
    • mn-fit
    • paw
  • fftw
    • ams
    • cassbeam
    • galan
    • glame
    • glfer
    • gmfsk
    • gpiv, gpivtools
    • grace, grace6
    • gramofile
    • libgpiv
    • meep
    • mpb
    • orsa
    • paul
    • pdl
    • rezound
    • sndobj
    • wsola
    • xmds
    • yorick-yeti
  • geant321
  • lush
  • mopac7
  • mpqc
    • ghemical (for libsc-dev)
    • libghemical (for libsc-dev)
  • octave2.9
  • psicode
  • pysparse
  • python-scipy
  • r-noncran-lindsey
  • saods9
  • scalapack
  • wsjt

As an alternative to g77, some packages will accept the pseudo-package "fortran77-compiler" which is also provided by "fort77", a wrapper for the Fortran-to-C translator, which already exists in armel. Others will accept the pseudo-package "fortran-compiler", which does not exist at all (gfortran provides "fortran95-compiler".)

?Anchor(gnat)

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 [http://gcc.gnu.org/ml/gcc/2001-11/msg00746.html 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, [http://gcc.gnu.org/ml/gcc/2008-02/msg00319.html 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.

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:

  • adabrowse
  • adacgi
  • adacontrol
  • adasockets
  • asis
  • ghdl (requires gnat-4.2)
  • gnade
  • gnat-glade
  • gnat-gps
  • libaunit
  • libaws
  • libflorist
  • libgtkada2
  • libopentoken
  • libtemplates-parser
  • libtexttools
  • libxmlada2
  • music123
  • plplot (only needed for extra language bindings: [http://bugs.debian.org/478891 bug] filed)

    • cl-plplot
    • gnudatalanguage
    • pdl

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

Interesting sites:

?Anchor(gobjc)

gobjc

GNU Objective C compiler, part of GCC, is explicitly disabled for armel, but works on arm.

Interestingly, the gobjc++, gobjc++-4.1 and gobjc++-4.2 binary packages can be built and are available on armel, though they cannot be installed because they require libobjc2 and the corresponding gobjc packages to run.

Dependent source packages:

  • gdb-avr
  • gnustep-base
  • gnustep-make
  • libfoundation1.0
  • libobjc-lf2
  • ragel

of which the gnustep items block 70 other source packages (i.e. the rest of ?GnuStep)

gdb would require gobjc, but it is currently set to build without it on armel.

gobjc is disabled for armel

In the debian package in debian/rules.defs:

 ifeq ($(DEB_TARGET_ARCH),armel)
   with_objc := disabled for armel
 endif

and in gcc-4.1 and gcc-4.2's ./configure

  arm*-*-linux-gnueabi)
    noconfigdirs="$noconfigdirs target-libffi target-qthreads"
    noconfigdirs="$noconfigdirs target-libjava target-libobjc"
    ;;

Enabling it in these two places in vanilla gcc-4.2.2 results in a build failure

/home/martin/arm/gcc-4.2.2/libobjc/exception.c: In function '__gnu_objc_personality_v0':           /home/martin/arm/gcc-4.2.2/libobjc/exception.c:173: error: '_URC_FATAL_PHASE1_ERROR' undeclared (first use in this function)

libobjc was disabled in GCC for ARM-EABI in 2005 when the -gnueabi patches went in [http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00948.html because ARM uses its own unwinding routines]. At the time, libffi and libjava were disabled too (as is still the case in Debian sources - see above) but these two have since been resolved in mainline GCC - see [http://www.busybox.net/lists/uclibc/2007-May/017971.html Fix ARM EABI signal unwinding, May 2007], [http://gcc.gnu.org/ml/java-patches/2007-q3/msg00091.html Enable gcj on ARM EABI, July 2007] and [http://gcc.gnu.org/ml/java/2007-08/msg00018.html Unwind_backtrace for ARM EABI, August 2007]. Similar unwinding strategies may work for libobjc.

Interestingly, GNUStep [http://amstradstuff.free.fr/maemo/gnustep.html has been made to work on Maemo], cross-compiled using the Scratchbox version of gcc-3.4 derived from Code Sourcery 2005q3.

?Anchor(gprolog)

gprolog

Lacks an ARM assembly code generator.

?Anchor(kaffe)

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 [http://www.kaffe.org/pipermail/kaffe/2008-January/141617.html 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 [http://www.mail-archive.com/kaffe@kaffe.org/msg12473.html on the kaffe mailing list], though this doesn't address EABI.

The ARM issues are finally addressed in Jan 2008 [http://www.mail-archive.com/kaffe@kaffe.org/msg13004.html 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 [http://www.nabble.com/cross-compile-error-td14965753.html here on nabble].

The same EABI system call fix will need propagating to [http://svn.perl.org/viewvc/parrot/trunk/src/jit/arm/jit_emit.h where this code was stolen from] in [http://www.parrotcode.org 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

?Anchor(mercury)

mercury

"A new logic/functional programming language"

Can only be compiled with gcc-3.4 [http://bugs.debian.org/297217 bug #297217], needing "lvalue casts" which were removed in gcc-4.0.

With [http://simplemachines.it/debian/patches/mercury-0.11.0.rotd.20040511+gcc4.diff this patch] applied, mercury-0.11.0.rotd.20040511-5 compiles on armel; a new release [http://bugs.debian.org/446665 is planned] from a more recent upstream snapshot that works with gcc-4.1.

?Anchor(mono)

mono

Mono CLI (.NET) runtime. Is built and included in the repository, but has [https://bugzilla.novell.com/show_bug.cgi?id=MONO80024 a bug], which causes the build of any package that uses it to fail.

Fixed in CVS; awaiting new upstream release. ~40 packages waiting.

Dependent source packages:

  • gtk-sharp2 (binary packages include libglib2.0-cil, libglade2.0-cil, libgtk2.0-cil)
    • avahi-sharp
    • banshee
    • beagle
    • blam
    • bless (*)
    • cowbell
    • dfo
    • drapes
    • evolution-sharp
    • f-spot
    • galago-gtk-sharp
    • galago-sharp
    • gbrainy (*)
    • gecko-sharp2 (*)
    • gfax (*)
    • gmime2.2 (*)
    • gnome-rdp (*)
    • gnome-sharp2, gnome-subtitles
    • graphmonkey (*)
    • gsf-sharp
    • gshare
    • gtksourceview-sharp2 (*)
    • hipo (*)
    • ipod-sharp
    • last-exit
    • lat (*)
    • mono-addins (*), mono-tools (*)
    • monodevelop (*)
    • muine
    • prj2make-sharp
    • stetic (*)
    • tomboy
  • ikvm
  • maybe others

(*) Arch-independent package unusable because of runtime dependency

?Anchor(mozart)

mozart

"An advanced development platform for intelligent, distributed applications"

[http://bugs.debian.org/428976 bug filed]

20 March 2008: Kevin Glynn, the package's maintainer, has made modifications to port it to several new platforms; here are [http://simplemachines.it/debian/patches/mozart-1.3.2.20060615+dfsg+armel.diff the armel-specific diffs] to the current source package, mozart-1.3.2.20060615+dfsg

?Anchor(oo2c)

oo2c

Optimizing Oberon-2 to ANSI-C Compiler.

Version 2.1.11-2 failed to build on armel on 16 July 2007 saying:

obj/OOC/SymbolTable/Predef.c: In function 'OOC_SymbolTable_Predef__CreatePredef':
obj/OOC/SymbolTable/Predef.c:174: error: 'NAN' undeclared (first use in this function)
obj/OOC/SymbolTable/Predef.c:174: error: (Each undeclared identifier is reported only once
obj/OOC/SymbolTable/Predef.c:174: error: for each function it appears in.)
make[1]: *** [bin/oo2c] Error 1

though it succeeded on all other architectures.

Version 2.1.11-3 instead manages to build the stage0 oo2c compiler, which then dies of segmentation faults building liboo2c.la.

?Anchor(php5)

php5

Version 5.2.3-1+armel's architecture-dependent binary packages are available in armel unreleased. Unfortunately, the current version is 5.2.4-2 and its architecture-independent binary packages are included in armel unstable but are uninstallable because they require matching versions of the architecture-dependent components.

Version, 5.2.4-2, failed to build on armel, saying:

checking build system type... Invalid configuration `arm-linux-gnueabi-gnu': machine `arm-linux-gnueabi' not recognized
configure: error: /bin/sh ../config.sub arm-linux-gnueabi-gnu failed

but no bug has been filed.

Its build dependencies cannot currently be installed because it requires libaprutil1-dev and libdb4.4-dev, libaprutil1-dev depends on libdb-dev but libdb-dev and libdb4.4-dev conflict. [http://bugs.debian.org/460562 bug] filed against package db.

Current version is 5.2.5-3

Libraries

?Anchor(dietlibc)

dietlibc

Needs upstream support for ARM EABI, see [http://bugs.debian.org/459482 Bug #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:

  • change to use the new system call interface
  • make it link to gcc's soft-float library
  • change function call entry/exit to allow thumb interworking (optional)

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:

  • fgetty
  • fnord
  • libdjbdns
  • libowfat
  • matrixssl
  • minit
  • skalibs
  • slidentd
  • util-vserver

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:

  • bglibs
  • cvm
  • e2fsprogs
  • integrit
  • runit

?Anchor(ffcall)

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. [http://mail-index.netbsd.org/port-arm/2008/01/30/0000.html NetBSD] and [http://www.nabble.com/Compiling-CLISP-on-ARM-Linux---ffi-problems-td11536294.html Clisp] people have encountered the same problem without solving it yet, though [http://mat.exon.name/logs/clisp Mat's clisp notes] make considerable progress on it.

Dependent source packages:

  • clisp
  • gnustep-base: libffcall1-dev (>= 1.10) [!arm], libffi4-dev [arm]

  • mlpcap

?Anchor(haskell-x11-extras)

haskell-x11-extras

Needs a change to the debian/rules file to avoid

[1 of 2] Compiling Graphics.X11.Xlib.Extras ( Graphics/X11/Xlib/Extras.hs, dist/build/Graphics/X11/Xlib/Extras.o )
ghc-6.6.1: panic! (the 'impossible' happened)
  (GHC version 6.6.1 for s390-ibm-linux):
        This compiler was built without a native code generator
    Use -fvia-C instead

See [http://bugs.debian.org/451903 bug].

?Anchor(lapack3)

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.                   

?Anchor(libffi)

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)

?Anchor(openmpi)

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.

These source packages need openmpi:

  • petsc

These would use it if it were available:

  • gromacs (for one package - it also has bindings to mpich)
  • rmpi

petsc

Parallel scientific library's build failed 20080415 in the testsuite:

TESTING: checkLibC from config.setCompilers(/build/buildd/petsc-2.3.3/python/BuildSystem/config/setCompilers.py:1119)make: *** [build-arch] Illegal instruction

Dependent source packages:

  • libmesh
  • petsc4py

?Anchor(purelibc)

purelibc

A system call virtualizing library, part of the [http://savannah.nongnu.org/projects/view-os/ 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.

?Anchor(shapelib)

shapelib

C API for reading and writing ?ArcView Shapefiles is included in the repository but is broken on armel. Linking anything with -lshp fails saying

/usr/bin/ld: conftest: hidden symbol `__aeabi_dcmpgt' in /usr/lib/gcc/arm-linux-gnueabi/4.2.3/libgcc.a(_cmpdf2.o) is referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status

This breaks the build of [#swscanner swscanner] and the following packages link to libshp:

  • gpsmanshp
  • xastir

During its Debian build, shapelib complains:

dpkg-shlibdeps: warning: symbol __aeabi_i2d used by debian/libshp1/usr/lib/libshp.so.1.0.1 found in none of the libraries.
dpkg-shlibdeps: warning: symbol __aeabi_dcmpeq used by debian/libshp1/usr/lib/libshp.so.1.0.1 found in none of the libraries.
dpkg-shlibdeps: warning: symbol __aeabi_dadd used by debian/libshp1/usr/lib/libshp.so.1.0.1 found in none of the libraries.
dpkg-shlibdeps: warning: symbol __aeabi_ddiv used by debian/libshp1/usr/lib/libshp.so.1.0.1 found in none of the libraries.
dpkg-shlibdeps: warning: symbol __aeabi_dmul used by debian/libshp1/usr/lib/libshp.so.1.0.1 found in none of the libraries.
dpkg-shlibdeps: warning: symbol __aeabi_dcmpgt used by debian/libshp1/usr/lib/libshp.so.1.0.1 found in none of the libraries.
dpkg-shlibdeps: warning: symbol __aeabi_d2iz used by debian/libshp1/usr/lib/libshp.so.1.0.1 found in none of the libraries.
dpkg-shlibdeps: warning: symbol __aeabi_dcmplt used by debian/libshp1/usr/lib/libshp.so.1.0.1 found in none of the libraries.
dpkg-shlibdeps: warning: symbol __aeabi_dsub used by debian/libshp1/usr/lib/libshp.so.1.0.1 found in none of the libraries.
dpkg-shlibdeps: warning: symbol __aeabi_dcmple used by debian/libshp1/usr/lib/libshp.so.1.0.1 found in none of the libraries.

which is strange, because dpkg-dev's dpkg-shlibdeps now blacklists these symbols (in /usr/share/perl5/Dpkg/Shlibs/SymbolFile.pm).

?Anchor(uclibc)

uclibc

Currently enabled on [arm] but not [armel].

The [http://bugs.debian.org/459482 dietlibc bug report] says that ARM EABI support has been done in uclibc and ARM EABI support is indeed present in the current unstable Debian source, version 0.9.27.

However, the Debian build fails on armel saying:

/usr/bin/make
make[1]: Entering directory `/home/martin/uclibc-0.9.27'
+ ./extra/scripts/fix_includes.sh -k /home/martin/uclibc-0.9.27/kernel -t arm
Unable to determine version for kernel headers
        provided in directory /home/martin/uclibc-0.9.27/kernel
make[1]: *** [headers] Error 1
make[1]: Leaving directory `/home/martin/uclibc-0.9.27'
make: *** [build-stamp] Error 2
dpkg-buildpackage: failure: debian/rules build gave error exit status 2

No other packages depend on uclibc on arm architectures.

System components

?Anchor(adeos)

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.

?Anchor(cacao)

cacao

Virtual machine for running Java programs.

Build of 0.98-2 fails on armel:

make[8]: Entering directory `/build/buildd/cacao-0.98/src/vm/jit/arm'
/bin/sh ../../../../libtool --mode=compile cc -I../../../../src -I../../../.. -I../../../../src -D__ARM__ -D__LINUX__ -ansi -pedantic -Wall -Wno-long-long -D_POSIX_C_SOURCE=199506L -D_XOPEN_SOURCE=500 -D_XOPEN_SOURCE_EXTENDED -D_BSD_SOURCE -g -Wall -O2 -c -o asmpart.lo asmpart.S
mkdir .libs
 cc -I../../../../src -I../../../.. -I../../../../src -D__ARM__ -D__LINUX__ -ansi -pedantic -Wall -Wno-long-long -D_POSIX_C_SOURCE=199506L -D_XOPEN_SOURCE=500 -D_XOPEN_SOURCE_EXTENDED -D_BSD_SOURCE -g -Wall -O2 -c asmpart.S  -fPIC -DPIC -o .libs/asmpart.o
asmpart.S: Assembler messages:
asmpart.S:366: Error: selected processor does not support `sfmfd f0,4,[r13]!'
asmpart.S:366: Error: selected processor does not support `sfmfd f4,4,[r13]!'
asmpart.S:374: Error: selected processor does not support `lfmfd f4,4,[r13]!'
asmpart.S:374: Error: selected processor does not support `lfmfd f0,4,[r13]!'

?Anchor(nsis)

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.33-1

?Anchor(openafs)

openafs

All binary packages are disabled for arm* in debian/control, but "kafs" kernel module is present in Debian arm kernels. Build says:

debian/rules build
ERROR: unsupported architecture

and fails much later: this is "sh debian/sysname" that is unable to map the dpkg --architecture output to an openafs system type, which is used to select a config file in src/config/param.alpha_linux_26.h. An arm_linux26 config file would need writing.

?Anchor(swh-plugins)

swh-plugins

Steve Harris's LADSPA (audio effects) plugins

Build dies saying

make[3]: Entering directory `/build/buildd/swh-plugins-0.4.15/util'
if arm-linux-gnueabi-gcc [...] -march=arm [...] -c -o rms.o rms.c; \
        then mv -f ".deps/rms.Tpo" ".deps/rms.Po"; else rm -f ".deps/rms.Tpo"; exit 1; fi
rms.c:1: error: bad value (arm) for -march= switch

?Anchor(tac-plus)

tac-plus

TACACS+ authentication daemon version 1:4.0.4.alpha-14 fails to build saying

make[1]: Entering directory `/build/buildd/tac-plus-4.0.4.alpha'
gcc   -DTCPWRAPPER -DMAXSESS -DTACPLUS_USERID=64005 -DTACPLUS_GROUPID=64005 -DUSE_LDAP -DUSE_PAM    -Wall -g -O2  -DTACPLUS_PIDFILE=\"/var/run/tac_plus.pid\" -L/usr/lib -I/usr/include/postgresql  -DUSE_DB -DDB_NULL -DDB_PGSQL    -c -o acct.o acct.c
In file included from acct.c:21:
tac_plus.h:712: error: conflicting types for 'sys_errlist'
/usr/include/bits/sys_errlist.h:28: error: previous declaration of 'sys_errlist' was here

every other architecture has built this as version 1:4.0.4.alpha-14+b1 or +b2, preumably with the obvious trivial modification, removing tac_plus.h line 712.

?Anchor(vnc4)

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.

?Anchor(xstow)

xstow

"An extended replacement of GNU Stow written in C++" failed to build on armel saying

make[3]: Entering directory `/build/buildd/xstow-0.5.1/src'
source='arg.cpp' object='arg.o' libtool=no \
        depfile='.deps/arg.Po' tmpdepfile='.deps/arg.TPo' \
        depmode=gcc3 /bin/sh ../depcomp \
        arm-linux-gnueabi-g++ -DHAVE_CONFIG_H -I..     -g -O2 -DNDEBUG -DNFORMAT -DSYSCONFDIR='"/etc/xstow"' -c -o arg.o `test -f arg.cpp || echo './'`arg.cpp
In file included from debug.h:4,
                 from arg.cpp:3:
format.h: In constructor 'Format::Format<A, B, C, D, E, F>::Format(const std::string&, A, B, C, D, E, F, unsigned int)':
format.h:651: error: 'snprintf' is not a member of 'std'
format.h:653: error: 'snprintf' is not a member of 'std'
format.h:655: error: 'snprintf' is not a member of 'std'
format.h:657: error: 'snprintf' is not a member of 'std'
format.h:659: error: 'snprintf' is not a member of 'std'
format.h:661: error: 'snprintf' is not a member of 'std'
make[3]: *** [arg.o] Error 1

It built fine on all other architectures.

Applications

?Anchor(exif)

exif

0.6.15-4 has [http://bugs.debian.org/445609 a bug] in the debian build process that makes the build fail on all architectures.

?Anchor(fenix)

fenix

Development environment for making 2D games

Build of 0.92a.dfsg1-3 fails on armel saying:

In file included from c_main.c:37:
../../include/fnx_loadlib.h:60: error: expected ')' before '*' token
c_main.c: In function 'compile_import':
c_main.c:358: error: 'dlfunc' undeclared (first use in this function)
c_main.c:358: error: (Each undeclared identifier is reported only once
c_main.c:358: error: for each function it appears in.)
c_main.c:358: error: expected ';' before 'RegisterFunctions'
c_main.c:424: error: 'ptr' undeclared (first use in this function)
c_main.c:424: error: 'soname' undeclared (first use in this function)
c_main.c:427: error: 'SIZEDLLEXT' undeclared (first use in this function)
c_main.c:427: error: expected ')' before 'DLLEXT'
c_main.c:427: error: expected ')' before 'DLLEXT'
...

but succeeds on all the other architectures.

?Anchor(gddrescue)

gddrescue

GNU data recovery tool.

Build of 1.2-1 fails on armel, saying

g++  -Wall -W -O2 -c -o ddrescue.o ddrescue.cc
ddrescue.cc: In function 'const char* format_num(long long int, long long int, int)':
ddrescue.cc:179: error: 'llabs' is not a member of 'std'
ddrescue.cc:179: error: 'llabs' is not a member of 'std'
ddrescue.cc:181: error: 'snprintf' is not a member of 'std'

?Anchor(galeon)

galeon

Web browser for Gnome desktop, is built and works with HTML pages but goes into an infinite loop if there is any ?JavaScript on a page.

?Anchor(gsynaptics)

gsynaptics

Configuration tool for Synaptics touchpad driver of X server.

[armel] not included in long list of architectures. The [arm] build currently fails saying

arm-linux-gnu-gcc: /usr/lib/libtasn1.so: No such file or directory

which is probably a buildd problem. It succeeds on armel, though it is noisy, saying:

dh_shlibdeps
dpkg-shlibdeps: warning: debian/gsynaptics/usr/bin/gsynaptics-init shouldn't be linked with libSM.so.6 (it uses none of its symbols).

for 29 libraries and

dpkg-shlibdeps: warning: debian/gsynaptics/usr/bin/gsynaptics shouldn't be linked with
libSM.so.6 (it uses none of its symbols).

for 28 libraries, which suggests that the build is a failure. No other architecture's build logs give these warning.

The resulting binary, like the similar packages ksynaptics and qsynaptics, is uninstallable for lack of the xserver-xorg-input-synaptics package.

Although the Synaptics Touchpad is a laptop-style mousepad, any ARM system that has USB interface could have a USB version of it.

?Anchor(happs)

happs

Haskell library for building Internet applications

Failed on armel 21 Dec 2007 for lack of GHC; may work now, but [http://bugs.debian.org/443053 a bug] prevents 0.8.8+darcs20070523-2 from building on anything except i386 and amd64].

?Anchor(iceape-browser)

iceape-browser

Web browser also known as mozilla-browser is in the repository but, when run, dies immediately saying:

iceape-bin: pthread_mutex_lock.c:285: __pthread_mutex_lock: Assertion
`(-(e)) != 3 || !robust' failed.
Aborted

?Anchor(iceweasel)

iceweasel

Web browser also known as firefox. Version 2.0.0.9-2 is included in the repository but fails to run. When launched it says

/usr/lib/iceweasel/firefox-bin: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking

then uses 100% CPU for a minute and a half (at 600 MHz), then hangs forever.

A fresh build of 2.0.0.11-1 runs for the same time then Segmentation faults.

LD_LIBRARY_PATH=/usr/lib/iceweasel gdb /usr/lib/iceweasel/firefox-bin gives:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x41007460 (LWP 6496)]
0x40049c74 in ?? () from /usr/lib/iceweasel/libmozjs.so
(gdb)

The current strategy is to get Firefox 3.0, whose alpha release is known to work on Maemo; see [http://bugs.debian.org/474281].

?Anchor(ktoon)

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-3.1

?Anchor(maxima)

maxima

Version 5.13.0-3 failed on armel 6 Jan 2008 saying

********************** Problem 258 ***************
Input:
/bin/sh: line 2:  5772 Aborted                 ./maxima-local --lisp=gcl --batch-string="run_testsuite(true,true);" >tmp 2>&1
make: *** [build-stamp] Error 134
dpkg-buildpackage: failure: debian/rules build gave error exit status 2

Unrecoverable error: Can't allocate.  Good-bye!..

which looks like a lack of virtual memory on the build daemon.

Current version is 5.13.0-3.1

?Anchor(nyello)

nyello

Command-line XMMS2 client. Version 0.5.0-1 failed to build on armel on 30 July 2007 saying:

if arm-linux-gnueabi-g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/xmms2      -g -O2 -MT playback.o -MD -MP -MF ".deps/playback.Tpo" -c -o playback.o playback.cc; \
        then mv -f ".deps/playback.Tpo" ".deps/playback.Po"; else rm -f ".deps/playback.Tpo"; exit 1; fi
/usr/include/xmms2/xmmsclient/xmmsclient.h: In member function 'Delayed<unsigned int>* Playback::getCurrentPosition()':
/usr/include/xmms2/xmmsclient/xmmsclient.h:93: error: too few arguments to function 'xmmsc_result_t* xmmsc_playlist_current_pos(xmmsc_connection_t*, const char*)'
playback.cc:138: error: at this point in file
make[3]: *** [playback.o] Error 1

though it succeeded on all other architectures.

?Anchor(qemu)

qemu

Processor emulator, doesn't yet understand gcc-4's assembly language, so needs gcc-3.4 at runtime. Support for running it on ARM processors is currently being tested. See [http://fabrice.bellard.free.fr/qemu/status.html the QEMU status page] and [http://bugs.debian.org/440425 this bug report].

?Anchor(swscanner)

swscanner

Simple Wireless Scanner. Failed to build on armel on

  • Tue 05 Jun 2007 15:19
  • Mon 18 Jun 2007 20:46
  • Thu 26 Jul 2007 16:50
  • Sat 11 Aug 2007 04:43
  • Wed 15 Aug 2007 14:27

saying

rm -f debian/debiandirs
if test ! -f /build/buildd/swscanner-0.2.2/Makefile;then \
                CFLAGS="-Wall -g -Wno-non-virtual-dtor -Wl,-z,defs" ./configure --disable-debug  --disable-rpath --prefix=/usr --libexecdir=/usr/bin --sysconfdir=/etc --libdir=/usr/lib --includedir=/usr/include/kde --with-qt-includes=/usr/include/qt3 --mandir=/usr/share/man --infodir=/usr/share/info --with-xinerama; \
        fi
checking build system type... armv5tel-unknown-linux-gnu
[...]
checking for main in -lshp... no
configure: error:       Can't find shapelib library (libqshp.so).
                        Be sure you have it installed, and try using --with-extra-libs argument
                        followed with the path where the libshp.so file is, to allow configure
                        find it out of standard locations.
make: *** [clean] Error 1

though it succeeded on all other architectures.

libshp.so is provided by binary package libshp-dev, which swscanner build-depends on, (libqshp.so does not exist in debian; this is just a typo in the verbose error message).

"configure.in" says:

AC_CHECK_LIB(shp, main, , [
              AC_MSG_ERROR([    Can't find shapelib library (libqshp.so).

which should succeed because "main" is defined in the "conftest.c" file. However, the compilation of "conftest.c" generated by this test fails saying:

configure:31080: gcc -o conftest -ansi -W -Wall -Wchar-subscripts -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -DNDEBUG -O2  -Wall -g -Wno-non-virtual-dtor -Wl,-z,defs -Wformat-security -Wmissing-format-attribute  -DQT_THREAD_SUPPORT  -D_REENTRANT  conftest.c -lshp   >&5
cc1: warning: command line option "-Wno-non-virtual-dtor" is valid for C++/ObjC++ but not for C
/usr/bin/ld: conftest: hidden symbol `__aeabi_dcmpgt' in /usr/lib/gcc/arm-linux-gnueabi/4.2.3/libgcc.a(_cmpdf2.o) is referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status

In fact, adding -lshp to any compilation gives the same error, which indicates a bug in [#shapelib shapelib].

?Anchor(varkon)

varkon

CAD system. Needs gcc-3.3 to build because of -fwritable-strings in Makefiles. The latest upstream version removes this need [http://bugs.debian.org/453009 Bug #453009]. Debian packages of the new version [https://lists.berlios.de/pipermail/varkon-discuss/2007-December/000410.html are now available] but it is currently orphaned and needs a Debian sponsor for it to upload.