9190
Comment: Remove joke
|
9217
gobjc++ packages need libobjc2 too
|
Deletions are marked like this. | Additions are marked like this. |
Line 163: | Line 163: |
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 the gobjc packages to run. | 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. |
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:
- bglibs
- bochs
- brltty
- ccontrol
- cgal
- cvm
- cvxopt
- dash
- esound
- gettext
- gnustep-base
- gst-plugins-base0.10: fixed in type-handling 0.2.23
- gtk2hs
- 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
- hmake
- integrit
- jack-audio-connection-kit
- kdeedu
- libdjbdns
- links2
- linux-2.6
- matrixssl
- openssh
- plplot
- python-numarray python-numeric python-numpy
- quintuple-agent
- samba
- shogun
- skalibs
- speech-dispatcher
- sqlrelay
- subversion
- wordtrans
Bugs have been filed against:
bigloo [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=455216 #455216]
directfb [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454769 #454796]
runit [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=455200 #455200]
type-handling [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=455486 #455486]
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.
Dependent source packages:
- gearhead
- hedgewars
- imapcopy
- lazarus.
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
- stegdetect
gcc-3.3-dependent source packages:
- varkon
g77
G77, the GNU Fortran 77 compiler, was not continued past gcc-3.4. From gcc-4, there is a separate "gfortran" program.
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 -> packages that depend on those in turn
arpack -> arpack++
atlas3 -> ...
blacs-mpi -> ...
blacs-pvm -> ...
- ...
libhdf4 -> dx, gdal, gnudatalanguage, h5utils, pdl.
lam -> alps-light1, blacs-mpi, gromacs, hdf5, netpipe, python-scientific, rmpi, scalapack, tessa, tree-puzzle, xmpi.
fftw -> ams, cassbeam, galan, glame, glfer, gmfsk, gpiv, gpivtools, grace, grace6, gramofile, libgpiv, meep, mpb, orsa, paul, pdl, rezound, sndobj, wsola, xmds, yorick-yeti
refblas3 -> apbs,
- saods9
- mpich
and many more.
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".
ghc6
Needed itself to compile itself; should now work. It, and its most closely dependent packages are available at [http://freaknet.org/martin/debian]
The speed of the compiler and the binaries it generates could be doubled by "registerising" GHC for ARM EABI - some changes to the source.
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
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
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 21 other source packages (i.e. all of gnustep!)
gdb would require gobjc, but it is currently set to build without it on armel.
Building the debian package
Enabling it in the debian package, the build of libstdc++ fails:
Enable gobjc in debian/rules.defs:
- ifeq ($(DEB_TARGET_ARCH),armel) - with_objc := disabled for armel - endif + #ifeq ($(DEB_TARGET_ARCH),armel) + # with_objc := disabled for armel + #endif
it fails to build libobjc++ and dies when trying to make the package.
dh_builddeb -pgobjc++-4.2 dpkg-deb: building package `gobjc++-4.2' in `../gobjc++-4.2_4.2.2-4_armel.deb'. trap '' 1 2 3 15; touch stamps/08-binary-stamp-objcxx; mv stamps/07-install-stamp-tmp stamps/07-install-stamp dh_testdir dh_testroot mv stamps/07-install-stamp stamps/07-install-stamp-tmp rm -f debian/tmp/usr/lib/libobjc.{la,so} mv debian/tmp/usr/lib/libobjc*.a debian/tmp/usr/lib/gcc/arm-linux-gnueabi/4.2/ mv: cannot stat `debian/tmp/usr/lib/libobjc*.a': No such file or directory make[1]: *** [stamps/08-binary-stamp-objc] Error 1
Building vanilla gobjc-4.2.2 from source
Configuring as for Debian (see output of gcc -v) , it says:
*** This configuration is not supported in the following subdirectories: target-libssp target-libffi target-libjava ''target-libobjc'' target-libada gnattools target-libgfortran target-boehm-gc target-zlib zlib fastjar
because in ./configure
arm*-*-linux-gnueabi) noconfigdirs="$noconfigdirs target-libffi target-qthreads" noconfigdirs="$noconfigdirs target-libjava target-libobjc" ;;
Remove that and try building it anyway. First it goes:
make[4]: Entering directory `/home/martin/arm/build-gcc-4.2.2/arm-linux-gnueabi/ libstdc++-v3/src' make[4]: *** No rule to make target `all'. Stop.
and arm-linux-gnueabi/libstdc++-v3/src/Makefile contains a single line:
MULTISUBDIR =
but there is libstdc++-v3/config.status, so we run that and it creates src/Makefile ok
Restart "make" and...
/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)
Libraries
fftw
Fastest Fourier Transform in the West. fftw3 is built but the legacy fftw(2) wants g77 to build its Fortran stubs. 22 packages waiting, none of which use the fortran stubs.
mono
Mono CLI (.NET) runtime. Bug [https://bugzilla.novell.com/show_bug.cgi?id=MONO80024 MONO80024] fixed in CVS; awaiting new upstream release. ~40 packages waiting
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.