27749
Comment: gnustep-base no longer needs libffcall1-dev
|
27813
amiga-fdisk has been enabled on armel but needs to be built
|
Deletions are marked like this. | Additions are marked like this. |
Line 23: | Line 23: |
* amiga-fdisk: armel has been enabled; package needs be built |
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 95% 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
- 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:
- adeos: Kernel patch for resource sharing. See [#adeos below]
- amiga-fdisk: armel has been enabled; package needs be built
- bglibs (if dietlibc is ported)
- cvm (if dietlibc is ported)
esound package libesd-alsa0 [http://bugs.debian.org/469860 bug filed]
- gnat-gdb (if gnat is ported)
- integrit (if dietlibc is ported)
jack-audio-connection-kit [http://bugs.debian.org/460084 bug filed]
kerry [http://bugs.debian.org/461091 bug filed]
- lazarus (if fpc is ported)
- libdjbdns (if dietlibc is ported)
- matrixssl (if dietlibc is ported)
- ocamlgsl: can now be built
- partman-ext2r0: "Add to partman support for old ext2 (revision 0)" - for debian installer only. Only provided on [arm mipsel]. Do we want this?
- runit (if dietlibc is ported)
- skalibs (if dietlibc is ported)
- uclibc: see [#uclibc below]
- usplash has been uploaded but not built
usplash-theme-debian: [http://bugs.debian.org/497147 bug filed]
whitelister [http://bugs.debian.org/408794 bug filed]
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 in unstable.
nwutil: Hardware utilities for ?NetWinder hardware, based on the StrongARM SA-110, which is armv4 and hence not supported in armel.
Languages
?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@yahoo.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(ecl)
ecl
ecl LISP Versions 0.9j and 0.9l crash with illegal instruction.
[http://bugs.debian.org/495351 Debian bug] filed, and [http://sourceforge.net/mailarchive/forum.php?thread_name=1219409420.4249.11.camel@laptop&forum_name=ecls-list on the ecl mailing list].
?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:
gearhead [http://bugs.debian.org/460067 bug filed] suggesting move to gpc
- hedgewars: definitely needs fpc not gpc
imapcopy [http://bugs.debian.org/460069 bug filed] suggesting move to gpc
lazarus: A Rapid Application Development tool for Free Pascal. Move to gpc [http://bugs.debian.org/460071 believed impossible]
Dependent binary packages not enabled on armel: libhdate-pascal ([http://bugs.debian.org/486095 bug] filed.
?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:
emile: (see [http://bugs.debian.org/463128 bug])
- qemu: see [#qemu below]
gcc-3.3-dependent source packages:
- varkon: see [#varkon below]
?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.
[http://gcc.gnu.org/ml/gcc/2008-05/msg00022.html 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:
- 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
- cl-plplot
- gnudatalanguage
- pdl
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 [http://bugs.debian.org/478891 bug 478891]).
Interesting sites:
[http://www.ada-france.org/debian/debian-ada-policy.html Debian Policy for Ada]
[http://gnuada.sourceforge.net/ The GNU Ada Team's source and binary distributions at ?SourceForge]. No ARM port is included.
[http://www.pegasoft.ca/resources/boblap/2.html Big Online Book of Linux Ada Programming, chapter 2: "Installing Gnat on Linux"]
[http://www.adacore.com/home/gnatpro/configurations ?AdaCore markets a version of gnat that runs on Windows ?VxWorks and targets XScale]
[http://www.rtems.com/wiki/index.php/RTEMSAda Instructions to build cross-gnat for RTEMS target] that successfully compiled "Hello world" to ARM.
[http://www.ada-auth.org/acats.html ACATS, the Ada Test Suite]
?Anchor(gprolog)
gprolog
Lacks an ARM assembly code generator.
?Anchor(ikvm)
ikvm
Java virtual machine/compiler implemented in .NET (Mono)
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
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 (on libffcall1-dev):
- clisp
- mlpcap
?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(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.
This source packages would build more completely if openmpi were available:
- petsc
These would use it if it were available:
- gromacs (for one binary package - it also has bindings to mpich)
- rmpi
petsc
Parallel scientific library
This builds in two flavours:
- openmpi version [alpha amd64 i386 ia64 powerpc sparc]
- lam version [!the above = armel mips mipsel s390]
The lam version does not produce libpetsc2.3.3-dev, which is required by:
- 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: TCL interface to libshp
xastir: currently set to libshp1 [!armel], but depends on gpsmanshp anyway.
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).
[http://bugs.debian.org/497160 Bug] filed.
?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.37-2, and it has only succeeded on i386 and amd64.
?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.
Applications
?Anchor(iceape-browser)
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.
?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-4 and fails thus on arm and armel.
?Anchor(maxima)
maxima
Version 5.16.3 failed to compile on armel 30 Aug 2008 saying
; - Loading binary file "binary-gcl/float.o" Loading binary-gcl/float.o Error in FPPREC1 [or a callee]: The function $RATDISREP is undefined. Fast links are on: do (use-fast-links nil) for debugging Broken at FPPREC1. Type :H for Help. Error in FPPREC1 [or a callee]: Can't extend the string. Fast links are on: do (use-fast-links nil) for debugging Broken at CONDITIONS::CLCS-UNIVERSAL-ERROR-HANDLER. 1 (Abort) Return to debug level 1. 2 Retry loading file "binary-gcl/float.o". 3 Return to top level.
?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. Fails to build on armel because [#shapelib shapelib] is broken on armel.
In detail:
checking for main in -lshp... no configure: error: Can't find shapelib library (libqshp.so).
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 but 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.