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 has built 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
At present, this file's covers a detailed analysis of packages identified by:
[http://unstable.buildd.net/buildd/armel_Failed.html the buildd's "Failed" list]
- Differences between "arm" and "armel" in the Sources files' Architecture: clauses
- Differences between "arm" and "armel" in the Sources files' Build-Depends: clauses
- People noticing that some packages have built on armel but do not work
?TableOfContents
arm/armel inconsistencies
The following packages build-depend/conflict with something on arm, but not on armel, or the source package is listed for Architecture: arm but not armel. Most of these are of the form "[long list of arches including arm]" or "[!arm]" and obviously just need armel added to the list. Some of these may already have bugs filed due to FTBFS on armel.
Missing from this list are source packages whose debian/control file specifies that some binary packages are to be built for a list or architectures including arm but not armel, whose symptom is that a source package appears to have built successfully on armel but did not produce any binary packages. Example: [http://bugs.debian.org/463816 libinotify-ruby]. Doing a full analysis of that means downloading and unpacking every single source package and analysing its debian/control file.
Please investigate, resolve and remove when resolved:
- adeos: Kernel patch for resource sharing. See [#adeos below]
atari-fdisk [http://bugs.debian.org/396326 bug filed]
- bglibs (if dietlibc is ported)
cgal (in non-free) [http://bugs.debian.org/460141 bug filed]
coriander [http://bugs.debian.org/436237 bug filed]
- cvm (if dietlibc is ported)
eciadsl [http://bugs.debian.org/408779 bug filed]
- gnat-gdb (if gnat is ported)
gnustep-base: libffcall1-dev (>= 1.10) [!arm], libffi4-dev [arm]. libffi4-dev is available in armel but gnustep-base also requires gobjc.
gsynaptics [http://bugs.debian.org/461088 bug filed] but see [#gsynaptics below]
gtk2hs [http://bugs.debian.org/458911 bug filed]
hfsprogs is currently [i386 powerpc] but is useful on any arch [http://bugs.debian.org/469151 bug filed]
- integrit (if dietlibc is ported)
ire [http://bugs.debian.org/408782 bug filed]
jack-audio-connection-kit [http://bugs.debian.org/460084 bug filed]
jamvm [http://bugs.debian.org/434846 bug filed] and fixed
kerry [http://bugs.debian.org/461091 bug filed] (an outdated version exists in the unstable repo despite being flagged not to build on armel!)
- lazarus (if fpc is ported)
- libdjbdns (if dietlibc is ported)
lcrash [http://bugs.debian.org/408784 bug filed]
- matrixssl (if dietlibc is ported)
mga-vid [http://bugs.debian.org/435384 bug filed]
mozart (in debian/control in source package) [http://bugs.debian.org/428976 bug filed]
- ocamlgsl: Blocked on binary libgsl0-dev from source gsl, which is blocked on refblas3-dev, which needs fortran transition.
- orpie: Blocked on binary libgsl0ldbl from source gsl, which is blocked on refblas3-dev, which needs fortran transition.
- partman-ext2r0: "Add to partman support for old ext2 (revision 0)" - for debian installer only. Only provided on [arm mipsel]. Do we want this?
- python-numarray python-numeric python-numpy: (see [#python-num below])
- runit (if dietlibc is ported)
- skalibs (if dietlibc is ported)
- uclibc: see [#uclibc below]
usplash is currently [amd64 i386 powerpc sparc] but is useful on any arch [http://bugs.debian.org/469279 bug filed]
whitelister [http://bugs.debian.org/408794 bug filed]
xfree86-driver-synaptics [http://bugs.debian.org/461551 bug filed]
xview [http://bugs.debian.org/408802 bug filed]
The following packages have been fixed but need to be built:
amiga-fdisk [http://bugs.debian.org/461081 bug] fixed 31 Jan 08
happs hmake haskell-alut haskell-arrows haskell-cgi haskell-fgl haskell-glut haskell-haskell-src haskell-hgl haskell-html haskell-hunit haskell-mtl haskell-network haskell-openal haskell-opengl haskell-quickcheck haskell-time haskell-x11 haskell-xhtml: The control files for these packages are generated by haskell-utils; bugs ([http://bugs.debian.org/460077 happs] [http://bugs.debian.org/460081 haskell-binary] [http://bugs.debian.org/460082 haskell-hlist] [http://bugs.debian.org/460083 haskell-x11-extras]) reassigned to haskell-utils and fixed 5 feb 08
libinotify-ruby [http://bugs.debian.org/463816 bug] fixed 29 feb 08
ltrace [http://bugs.debian.org/450931 bug] fixed 3 feb 08
lua-gtk [http://bugs.debian.org/464140 bug] fixed 24 feb 08
shogun [http://bugs.debian.org/460096 bug] fixed 12 feb 08
spamoracle [http://bugs.debian.org/429558 bug] fixed 2 mar 08
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.
Languages
?Anchor(clisp)
clisp
Common Lisp works on arm, binary packages does not include armel in the source package's debian/control Package: sections, though it works on arm.
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].
Dependent packages:
- mcvs
- xindy
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'
Dependent packages:
- minlog
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 [http://bugs.debian.org/460071 bug filed] suggesting move to gpc
Dependent binary packages not enabled on armel: libhdate-pascal.
gcc-3.4
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:
prc-tools [http://bugs.debian.org/343016 bug filed]
lisaac [http://bugs.debian.org/440426 bug filed]
- qemu: see [#qemu below]
stegdetect [http://bugs.debian.org/440429 bug filed]
gcc-3.3-dependent source packages:
emile 0.11-1 updates to 3.4 but not to gcc-4 (see [http://bugs.debian.org/463128 bug])
- varkon: see [#varkon below]
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
- octave2.9
- psicode
- pysparse
- python-numarray, python-numpy
- gdal
- gnudatalanguage
- gnuradio
- matplotlib
- modelbuilder
- necpp
- petsc4py
- plplot
- pynifty
- pyqwt, pwqwt3d, pwqwt5
- pytables
- python-imaging
- python-scipy-core
- python-visual
- pywavelets
- rpy
- shogun
- python-scipy
- r-noncran-lindsey
- refblas3
- apbs
- gimp-plugin-registry (see above)
- gsl
- ocamlgsl [armel] needs adding
- lapack3 (see above)
- saods9
- scalapack
- wsjt
(./): fixed and built, but dependent packages not built yet
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".)
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.
No Ada binaries site or other operating system distribution that supports ARM (NetBSD) 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.
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]
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.
kaffe
A JVM to run Java bytecode
Version 2:1.1.8-1 failed to build on armel on 4 Oct 2007 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
The current version is 2:1.1.8-3
mercury
"A new logic/functional programming language"
Build of version 0.11.0.rotd.20040511-5 failed on armel on Jun 15, 2007 saying:
> make[3]: Entering directory `/build/buildd/mercury-0.11.0.rotd.20040511/build/mercury/runtime' > ../scripts/mgnuc --grade hlc.gc --no-mercury-stdlib-dir --c-debug --no-ansi -- -I../boehm_gc -I../boehm_gc/include -I../mps_gc/code -DMERCURY_BOOTSTRAP_H -DMERCURY_CONF_BOOTSTRAP_H -c mercury_deep_copy.c -o mercury_deep_copy.o > In file included from mercury_deep_copy.c:52: > mercury_deep_copy_body.h: In function 'MR_deep_copy': > mercury_deep_copy_body.h:387: error: invalid lvalue in assignment > mercury_deep_copy_body.h:425: error: invalid lvalue in assignment
though it has built fine on the other architectures.
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
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.
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.
The current mainstream version, 5.2.4-2, fails 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 and libdb-dev and libdb4.4-dev conflict. [http://bugs.debian.org/460562 bug] filed against package db.
Libraries
dietlibc
Needs upstream support for ARM EABI, see [http://bugs.debian.org/459482 Bug #459482].
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
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.
freetds
MS SQL and Sybase client library needs armel patches; the patches attached to [http://bugs.debian.org/441736 bug #441736] are not usable because they contain a lot of machine-generated noise. See comments in the bug report for what needs resolving.
The build currently dies saying:
./debian/dh_makeshlibs -a -Xtdsodbc dh_makeshlibs: Compatibility levels before 4 are deprecated. Error: added symbols in libtdssrv.so.2: Base __aeabi_f2ulz Please update the library manifest at ./debian/dh_makeshlibs line 255. make: *** [binary-arch] Error 255
because EABI floating point symbols are being exported.
A version of its binary packages are currently available in armel "unreleased".
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.
lapack's arm problems on the old arm port are [http://osdir.com/ml/debian.ports.arm/2003-11/msg00003.html presumed to be due to the middle-endian floating point format used in the old arm port].
The armel version has been [http://www.mail-archive.com/debian-python@lists.debian.org/msg04366.html moved to gfortran] but the big fat warning is the same when it is installed.
Packages that build-depend on it:
- abinit
- cvxopt [arm] - armel needs adding
- ghemical
- gimp-plugin-registry (for sid's version 0.5.1. The armel unstable repo contains a binary package of version 0.3.2-1)
- gretl
- harminv
- libghemical
- libitpp
- meep
- mpb
- octave2.1, octave2.9, octave3.0
- openmx
- petsc
- libmesh
- petsc4py
- plplot [arm m68k] - armel needs adding
- suitesparse
- lp-solve
libhdf4
Hierarchical Data Format library, needs g77->gfortran patches including and uploading. See [http://bugs.debian.org/456297 bug #456297]
Its binary packages are currently available in armel "unreleased".
libinotify-ruby
The buildd logs claim this is an arch-all package, but it isn't. It should generate two arch-dep packages, but just doesn't on armel. [http://bugs.debian.org/463816 bug filed]
libstatgrab
Fails on armel, saying:
checking for libdevinfo.h... no configure: error: Cannot build on unknown OS: linux-gnueabi make: *** [config.status] Error 1
purelibc
Version 0.2-1 failed to build on armel on 15 Jul 2007 saying:
socketcalls.c: In function 'pure_int_socketcall': socketcalls.c:85: error: '__NR_socketcall' undeclared (first use in this function) socketcalls.c:85: error: (Each undeclared identifier is reported only once socketcalls.c:85: error: for each function it appears in.) make[2]: *** [libpurelibc_la-socketcalls.lo] Error 1
although it is available on arm (as well as i386 m68k and powerpc).
?Anchor(python-num)
python-numarray python-numeric python-numpy
Numeric Extensions to Python
Binary packages for 24.2-7 are currently available in armel "unreleased"; the current unstable version is 24.2-8.
A proper build is waiting for the build dependency, refblas3-dev, to become available.
These packages explicitly disable lapack3 and refblas3 support on [arm]:
- python-numarray
- Build-Depends: refblas3 [!arm], refblas3-dev [!arm], lapack3-dev [!arm]
- python-numeric
- Build-Depends: refblas3-dev [!arm !m68k], lapack3-dev [!arm !m68k]
- Build-Conflicts: lapack-dev [!arm !m68k], blas-dev [!arm !m68k]
- python-numpy
- Build-Depends: lapack3-dev [!arm !m68k], refblas3-dev [!arm !m68k]
a trick which would also solve the problem on armel.
Dependent source package:
- python-gtk2
?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.
?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.
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]!'
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
srtp
"Secure RTP". The build of version 1.4.2.dfsg-5 failed on armel on 3 Sep 2007, with testsuite failures, saying:
running libsrtp test applications... crypto/test/cipher_driver -v >/dev/null crypto/test/kernel_driver -v >/dev/null test/rdbx_driver -v >/dev/null make[1]: *** [runtest] Error 255
Current version is 1.4.4~dfsg-1, and 1.4.2.dfsg-4 is in the armel unstable repository.
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
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.
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.
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
ardour
Digital audio workstation. Version 1:2.1-1 failed to build on 4 Oct 2007 saying:
gtk2_ardour/editor_mouse.cc:1533: error: call of overloaded 'abs(nframes64_t)' is ambiguous
Current unstable source is 1:2.2-1
It is worrying that, during configuration, it says:
system triple: armv5tel-unknown-linux-gnu ******************************* detected DIST_TARGET = i686 ******************************* NameError: name 'build_host_supports_sse' is not defined: File "/home/martin/ardour-2.2/SConstruct", line 689: if build_host_supports_sse != 1: make: [scons-clean] Error 2 (ignored)
but it builds fine on armel anyway.
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.
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.
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(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.
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 a bug] prevents 0.8.8+darcs20070523-2 from building on anything except i386 and amd64].
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
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)
while debug mode "iceweasel -g" gives:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x410077b0 (LWP 6742)] 0x40d605c8 in ?? () from /lib/libc.so.6
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
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
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.
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.