Differences between revisions 73 and 74
Revision 73 as of 2008-01-10 12:35:34
Size: 13643
Editor: MartinGuy
Comment: Add dietlibc section
Revision 74 as of 2008-01-10 13:23:35
Size: 14087
Editor: MartinGuy
Comment: pro-tem saving of work
Deletions are marked like this. Additions are marked like this.
Line 30: Line 30:
 * cvxopt
 * directfb http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454769 bug filed]
 * cvxopt: atlas3-base-dev [!arm], lapack3-dev [arm]
 * directfb [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454769 bug filed]
Line 33: Line 33:
 * gnustep-base  * gnustep-base: libffcall1-dev (>= 1.10) [!arm], libffi4-dev [arm]
Line 36: Line 36:
 * happs
 * haskell-alut haskell-arrows haskell-binary haskell-cgi haskell-fgl haskell-glut haskell-haskell-src haskell-hgl haskell-hlist haskell-html haskell-hunit haskell-mtl haskell-network haskell-openal haskell-opengl haskell-quickcheck haskell-time haskell-x11 haskell-x11-extras haskell-xhtml
 * happs [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460077 bug filed]
 * 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: private mail sento to maintainer Ian Lynagh <igloo@debian.org>
 * haskell-binary [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460081 bug filed]
 * haskell-hlist [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460082 bug filed]
 * haskell-x
11-extras [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460083 bug filed]

This page tracks the problems with individual packages in the 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:

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:

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

    • 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)
    • 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:

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

Libraries

dietlibc

Needs porting, see [http://bugs.debian.org/425971 Bug #425971].

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

Applications

qemu

Processor emulator. Requires gcc-3.4 because it compiles machine code into C fragment, munges the assembly language and then assembles them, but doesn't understand gcc-4 output. It has also not been ported to work on ARM.

Suggested solution: Not-for-us

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.