Debian Bug report logs - #19471
Could there be a multi-arch binutils package?

version graph

Package: binutils; Maintainer for binutils is Matthias Klose <doko@debian.org>; Source for binutils is src:binutils.

Reported by: Roman.Hodek@informatik.uni-erlangen.de

Date: Wed, 11 Mar 1998 10:03:01 UTC

Severity: wishlist

Found in version 2.8.1.0.19-1

Done: unknown

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Galen Hazelwood <galenh@micron.net>:
Bug#19471; Package binutils. Full text and rfc822 format available.

Acknowledgement sent to Roman.Hodek@informatik.uni-erlangen.de:
New bug report received and forwarded. Copy sent to Galen Hazelwood <galenh@micron.net>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>
To: submit@bugs.debian.org
Subject: Could there be a multi-arch binutils package?
Date: Wed, 11 Mar 1998 09:52:24 GMT
Package: binutils
Version: 2.8.1.0.19-1
Severity: wishlist

Hi Galen!

Christian Schwarz and me have built an improvement into Lintian so
that it is basically able to also check binary packages of another
architecture than the one of the test machine. But for this, an
multi-arch objdump is necessary... So we come up with this wishlist
item :-) It would be fine if you could generate another binary package
from the binutils source (called, for example, "binutils-multiarch")
that contains such multi-arch binutils, to make it easier for users to
get them and install them.

You probably know that most binutils can be build with support for
multiple target formats. For example, I do lots of i386->m68k cross
compiling and have some self-compiled binutils (objdump, nm, ...) with
support for i386 *and* m68k binaries installed (installation done
with diversions...):

  $ objdump --help
  [...]
  objdump: supported targets: elf32-i386 a.out-i386-linux elf32-m68k a.out-m68k-linux srec symbolsrec tekhex binary ihex trad-core

This come very handy, because I don't have to use a separate binary
(e.g. m68k-linux-objdump) for m68k objects, and don't have to remember
which one to use :-)

Now Lintian also uses objdump for extracting some information from
executables and libraries, but this requires an objdump that supports
the arch of the executables. I've tested Lintian successfully on m68k
packages with my multi-arch objdump, it works fine.

Ok, I don't think that very many people will need those multi-arch
binutils, but it could be convenient to have them as a Debian package.
For example, if one wants to run Lintian on packages that aren't for
the arch of the testing machine... :-) But a multi-arch package would
also be useful for people (like me) that do lots of cross-compiling.

When configuring binutils, you can select the supported targets as:

  ./configure ... --enable-targets="i386-linux i386-linuxaout m68k-linux m68k-linuxaout ..."

I'd list all Debian architectures here that are supported by
configure. The package would best install those multi-arch binaries
over the old (single-arch) ones, using diversions. And here's a list
of the binutils for which I surely know they work all ok for multiple
archs:

  nm
  objdump
  objcopy
  strings
  strip
  size

The only program that surely doesn't work with multiple archs is 'as'
(it misses support for it in the source, at least this was the case in
~ 2.8.0). A multi-arch ld is also not very handy, because you often
have to specify the output format manually, otherwise can use its
default format, which is the native one, and this is bad for cross
compiling. So one better uses a specialized cross-ld for this. Another
binary I once had trouble with was 'ar'. It also sometimes uses the
wrong output format when cross-compiling, so I use single-arch ar's.

I haven't tested the remaining ones (ranlib, c++filt, addr2line, gasp,
gprof) myself yet. c++filt, addr2line, and gasp should be uncritial in
this respect. ranlib could have the same problem as ar, but don't
know... It has exactly one input and thus should be able to get the
output format right. gprof: Don't know how it depends on binary
formats... :-(

Roman


Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 23 08:02:55 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.