21796
Comment: Link to ArmEabiPort early in page
|
21796
change nictool bug number to unfixed previous report (old bug merged)
|
Deletions are marked like this. | Additions are marked like this. |
Line 46: | Line 46: |
* nictools-pci: Currently provided on [alpha amd64 arm i386]. Linksys NSLU2s have a PCI bus but the network chip is not on it. Do any of [http://packages.debian.org/sid/nictools-pci the specific chips this package supports] exist on the PCI bus of any armv4t+ box? [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461096 bug filed] anyway | * nictools-pci: Currently provided on [alpha amd64 arm i386]. Linksys NSLU2s have a PCI bus but the network chip is not on it. Do any of [http://packages.debian.org/sid/nictools-pci the specific chips this package supports] exist on the PCI bus of any armv4t+ box? [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408787 bug filed] anyway |
This page tracks the problems with individual packages in the [http://wiki.debian.org/ArmEabiPort Debian armel port].
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 (mostly other languages)
- Depend on something blocked by the above
?TableOfContents
arm/armel inconsistencies
Joey Hess says in [http://lists.debian.org/debian-arm/2007/12/msg00038.html a message to debian-arm@lists.debian.org]
"The following packages build-depend/conflict with something on arm, but not on 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."
Please investigate, resolve and remove from this list:
- adeos: Kernel patch for resource sharing. See notes below
amiga-fdisk: [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461081 bug filed]
atari-fdisk [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=396326 bug filed]
- bglibs (if dietlibc is ported)
cgal (in non-free) [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460141 bug filed]
coriander [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436237 bug filed]
- cvm (if dietlibc is ported)
- cvxopt:
- Build-Depends: atlas3-base-dev [!arm], lapack3-dev [arm]
ddccontrol builds ok on armel; [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461089 bug filed] - new version 0.4.2-4 uploaded
eciadsl [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408779 bug filed]
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/cgi-bin/bugreport.cgi?bug=461088 bug filed] but see below
gtk2hs [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458911 bug filed]
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 file for these packages is generated by haskell-utils; bugs filed against [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460077 happs] [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460081 haskell-binary] [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460082 haskell-hlist] [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460083 haskell-x11-extras] have been reassigned to it
ibam builds ok on armel [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461090 bug filed]
- integrit (if dietlibc is ported)
ire [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408782 bug filed]
jack-audio-connection-kit [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460084 bug filed]
jamvm [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=434846 bug filed]
kerry [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461091 bug filed] (an outdated exists in the unstable repo despite being flagged not to build on armel!)
- libdjbdns (if dietlibc is ported)
lcrash [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408784 bug filed]
ltrace [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=450931 bug and patches filed]
- matrixssl (if dietlibc is ported)
mga-vid [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=435384 bug filed]
nictools-pci: Currently provided on [alpha amd64 arm i386]. Linksys NSLU2s have a PCI bus but the network chip is not on it. Do any of [http://packages.debian.org/sid/nictools-pci the specific chips this package supports] exist on the PCI bus of any armv4t+ box? [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408787 bug filed] anyway
- 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?
- plplot:
- Build-Depends: atlas3-base-dev [!arm !m68k], lapack3-dev [arm m68k], refblas3-dev [arm m68k]
- Build-Depends: java-gcj-compat-dev [!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]
- runit (if dietlibc is ported)
shogun [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460096 bug filed]
- skalibs (if dietlibc is ported)
spamoracle [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=429558 bug filed]
- uclibc: see below
whitelister [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408794 bug filed]
xfree86-driver-synaptics: provides X.org driver for Synaptics ?TouchPad. Do ARMs ever have a Synaptics ?TouchPad?
xview [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408802 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!)
- lazarus (Application Development tool for free pascal compiler, which has not been ported to armel yet)
- 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
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/cgi-bin/bugreport.cgi?bug=460067 bug filed] suggesting move to gpc
- hedgewars: definitely needs fpc not gpc
imapcopy [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460069 bug filed] suggesting move to gpc
lazarus: A Rapid Application Development tool for Free Pascal [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=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
- lisaac
- qemu (see below)
- stegdetect
gcc-3.3-dependent source packages:
- emile
- varkon (see 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
- dsdp
- 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
- lam
- alps-light1
- blacs-mpi
- gromacs
- hdf5
- netpipe
- python-scientific
- rmpi
- scalapack
- tessa
- tree-puzzle
- xmpi
- lapack3
- 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
- openmx
- petsc
- libmesh
- petsc4py
- plplot [arm m68k] - armel needs adding
- libhdf4
- dx
- gdal
- gnudatalanguage
- h5utils
- pdl
- lush
- mopac7
- mpich
- mpqc
- octave2.9
- psicode
- pysparse
- python-numarray, python-numpy
- 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
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 two gnat packages: gnat-4.1 and gnat-4.2.
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.
Dependent source packages:
- adacgi
- adacontrol
- adasockets
- asis
- ghdl (requires gnat-4.2)
- gnade
- gnat-glade
- gnat-gps
- libaunit
- libaws
- libflorist
- libgtkada2
- libopentoken
- libtemplates-parser
- libtexttools
- libxmlada2
- music123
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.
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
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].
Dependent source packages:
- bglibs
- bcron
- ezmlm-browse
- mailfront
- twoftpd
- ucspi-proxy
- ucspi-unix
- cvm (also needs bglibs)
- fgetty
- fnord
- integrit
- libdjbdns
- libowfat
- matrixssl
- minit
- runit
- skalibs
- slidentd
- util-vserver
freetds
MS SQL and Sybase client library needs armel patches; the patches attached to [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=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".
libhdf4
Hierarchical Data Format library, needs g77->gfortran patches including and uploading. See [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456297 bug #456297]
Its binary packages are currently available in armel "unreleased".
python-numeric
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.
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
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.
kernel-package
[http://bugs.debian.org/425971 Bug 425971] blocks automatic building of the Linux kernel packages. Fixes have been applied; waiting for the mainline version subsequent to 11.001 to be uploaded (check [http://packages.debian.org/source/sid/kernel-package here] to see whether this has happened yet).
Applications
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.
Can an ARM system actually *have* a Synaptics ?TouchPad?
qemu
Processor emulator. Requires gcc-3.4 because it compiles machine code into C fragments, munges the assembly language and then assembles them. In late 2006, at least, it didn't understand gcc-4 output and so needed gcc-3.4 at runtime. Upstream, an ARM port of QEMU is being tested but is not reliable yet.
Suggested solution: Not-for-us
subversion
Binary packages for version 1.4.4dfsg1-1+armel are available in armel "unreleased"; the mainline version is 1.4.4dfsg1-1. No bug has been filed.
Its build dependencies cannot currently be satisfied for the same libdb-dev reasons that block php5 (see [http://bugs.debian.org/460562 bug #460562])
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.