Differences between revisions 23 and 24
Revision 23 as of 2007-12-09 19:06:43
Size: 9854
Editor: MartinGuy
Comment:
Revision 24 as of 2007-12-10 11:35:06
Size: 9900
Editor: ?LoicMinier
Comment:
Deletions are marked like this. Additions are marked like this.
Line 35: Line 35:
 * gst-plugins-base0.10  * gst-plugins-base0.10: seems to be a type-handling issue; 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 message <20071207222505.GA2501@kitenet.net> to debian-arm@lists.debian.org 07/12/2007 17:25

"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: seems to be a type-handling issue; bug filed
  • 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 #455216
  • directfb #454769
  • runit #455200

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. Does anyone fancy taking the CodeSourcery mods as diffs and making a huge debian patch to enable ARM EABI in gcc-3.4.4? :)

Examples of gcc < 4.0 dependencies:

  • QEMU requires gcc-3.4 because it compiles machine code into fragments of C, compiles them and edits the generated assembly language before assembling it. Anyway, there is no support for ARM asm in QEMU!
  • Varkon needs gcc-3.3 because it needs -fwritable-strings.

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.

gcl

Gnu Common Lisp, is another failing package which explicitly selects gcc-3.4 only for the arm build (and using gcc-4, as it does for armel at present, fails). For this, the ARM support in gcl needs porting to gcc-4.X, as has already been done for the other CPUs it supports.

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.

gobjc

Is explicitly disabled for armel. 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

Try a vanilla build of gcc-4.2.2 with gobjc:

 *** 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"
    ;;

If we remove that and try building it anyway, first

 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 (!)

So we restart "make" and...

groff

On systems installed from the ftp.gnuab.org, troff (from groff-base_1.18.1.1-14) always gives immediate segfault.

Repeat-by:

$ troff
Segmentation fault.
$

On an system recently installed from ftp.debian-ports.org instead, it works fine. Updating the gnuab-started systems from the debian-ports repo doesn't fix it.

Trying to dpkg-buildpackage groff on a gnuab-installed system dies as soon as it tries to run the generated executable:

GROFF_COMMAND_PREFIX=''; export GROFF_COMMAND_PREFIX; GROFF_BIN_PATH=`echo /home
/martin/arm/groff-1.18.1.1/src/roff/groff /home/martin/arm/groff-1.18.1.1/src/ro
ff/troff /home/martin/arm/groff-1.18.1.1/src/devices/grops | sed -e 's|  *|:|g'`
; export GROFF_BIN_PATH; /home/martin/arm/groff-1.18.1.1/src/roff/groff/groff -F
/home/martin/arm/groff-1.18.1.1/font -F/home/martin/arm/groff-1.18.1.1/font -M/h
ome/martin/arm/groff-1.18.1.1/tmac -M/home/martin/arm/groff-1.18.1.1/tmac -M/hom
e/martin/arm/groff-1.18.1.1/contrib/mom -Tps -mom examples/letter.mom >examples/
letter.ps
/home/martin/arm/groff-1.18.1.1/src/roff/groff/groff: troff: Segmentation fault

/home/martin/arm/groff-1.18.1.1$ gdb src/roff/troff/troff
(gdb) run
Program received signal SIGSEGV, Segmentation fault.
0x000226c0 in input_stack::get_location (allow_macro=0, filenamep=0xbeedcacc,
    linenop=0xbeedcac8) at input.cc:565
565         if (p->get_location(allow_macro, filenamep, linenop))
(gdb) backtrace
#0  0x000226c0 in input_stack::get_location (allow_macro=0,
    filenamep=0xbeedcacc, linenop=0xbeedcac8) at input.cc:565
#1  0x00023e64 in do_error (type=FATAL, format=0x4a9a8 "too many symbols",
    arg1=@0x5d3a8, arg2=@0x5d3a8, arg3=@0x5d3a8) at input.cc:7527
#2  0x000240b4 in fatal (format=0x0, arg1=@0x0, arg2=@0x240b4,
    arg3=<value optimized out>) at input.cc:7603
#3  0x000392f0 in symbol (this=0x598ec, p=0x45934 "fl", how=19)
    at symbol.cc:111
#4  0x00017cb8 in __static_initialization_and_destruction_0 (
    __initialize_p=<value optimized out>, __priority=<value optimized out>)
    at node.cc:592
#5  0x00044c48 in __libc_csu_init ()
#6  0x401d7d68 in __libc_start_main () from /lib/libc.so.6
#7  0x00009a4c in _start ()

input.cc:565 is:

int input_stack::get_location(int allow_macro, const char **filenamep, int *line
nop)
{
  for (input_iterator *p = top; p; p = p->next)
    if (p->get_location(allow_macro, filenamep, linenop))   <--
      return 1;
  return 0;
}

 top=(input_iterator *) 0x59edc
 p=(input_iterator *) 0x59edc
 p->get_location=0x35420
 *filenamep=0x709e0  **filenamep='\0'
 linenop=(int *) 0xbeedcac8   *linenop=1076776988
 get_location=0x22678 == input_iterator::get_location

Which all look feasible, so what's segfaulting?

The really strange thing is that the buildd logs say that the buildd ALL6500 built groff and successfully ran the binary before making package out of it on 18 nov 2007. See [http://experimental.ftbfs.de/build.php?arch=armel&pkg=groff&ver=1.18.1.1-14]

The latest groff-base is 1.18.1.1-15, but updating to that (and a more recent libstdc++ package) doesn't fix troff on the gnuab installations.

I've tried building it

  • with gcc-4.1 instead of the usual 4.2: no change.
  • with DEB_BUILD_OPTIONS=noopt: no change.

The problem is rootfs-dependent, not cpu-type dependent; two rootfsses independently installed from gnuab show the same behaviour; different CPUs (armv4t, armv5t) running the two kinds of rootfs exhibit the same behaviour on each.

The troff binary /usr/bin/troff and the dynamic libraries that troff calls:

n2100:/home/martin# ldd /usr/bin/troff
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x40026000)
        libm.so.6 => /lib/libm.so.6 (0x40105000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x401b0000)
        libc.so.6 => /lib/libc.so.6 (0x401c3000)
        /lib/ld-linux.so.3 (0x40000000)

are bit-for-bit identical on the two systems.

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]; the Debian package is currently orphaned but should be adopted in mid December 2007 and updated to upstream.