Re: weird limitation on the system's binutils

From: Peter Jeremy <peterjeremy_at_optushome.com.au>
Date: Sat, 1 Jul 2006 21:55:08 +1000
On Sat, 2006-Jul-01 00:09:08 -0400, Mikhail Teterin wrote:
>I'm wondering, why the bfd and related bits and pieces of binutils are built 
>to support only the architecture(s), that can natively run on the system?

IMHO, the FreeBSD base system should provide tools for doing native
development - anything beyond that belongs in ports.  Given that
binutils supports quite an extensive range of targets (of thr order of
100), building them all is impractical and a waste of resources for
virtually everyone who uses FreeBSD.

>Why can't I use gdb or objdump on FreeBSD/i386 to analyze a core file, or a 
>binary from another FreeBSD or even from a non-FreeBSD system?

You can if you install the relevant ports.

>The tools themselves support that. The sources (bfd-vectors) for all other 
>supported architectures are part of the tree (under contrib/). So, why not 
>build them?

My reading of contrib/binutils suggests that files for targets not
related to FreeBSD are in the exclude/delete list and aren't imported
into the FreeBSD repository.

>If it really is SO much of a bloat, why do we install gdb, etc. in the first 
>place?

I'm happy with buildworld building a toolchain that supports native
development on FreeBSD.  I have used FreeBSD for cross-development and
I'm happy to manually install a toolchain to support the target I'm
developing for.  I'd be somewhat concerned if buildworld decided to
build a toolchain that supported around several targets for each of
around 100 different processors - the vast majority I'd never use.

>P.S. What I also want is the /lib/libbfd.so and friends, so I (and the 15 
>devel/*binutils ports) can build my own tools linking with it. Unfortunately, 
>that too remains impossible...

libbdf.a is built by /usr/src/gnu/usr.bin/binutils/libbfd/Makefile.
That should be a fairly simple change to arrange for it to build and
install the .so as well.

-- 
Peter Jeremy

Received on Sat Jul 01 2006 - 09:55:30 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:57 UTC