Re: weird limitation on the system's binutils

On Wed, Jul 05, 2006 at 05:18:07PM +0100, Robert Watson wrote:
> My recollection is that we got to where we are today precisely because the 
> various GNU tools (gdb, gcc, etc) relied on versions of bfd "as cut" at the 
> point where the tool revisions were released.  This meant that they could 
> not share bfd versions between tools, since tools were often released at 
> different dates, and the versions of bfd with different tools were 
> incompatible.  The conclusion was that by statically linking the specific 
> compatible versions into the binaries, and by not shipping a specific bfd 
> as part of the base system, we avoided numerous compatibility issues, as 
> well as avoided committing consumers of the system to a particular bfd 
> revision that might be incompatible with what they want to run in the way 
> of their own cross tools, etc.  Perhaps the world has changed since that 
> time, but those sound like pretty good reasons to me.  So these are my 
> recollections, but since I'm not an expert in our toolchain bits, I could 
> be off in the woods somewhere.

Historical note: I once had support for multiple architectures built into
FreeBSD's GNU tools with the host architecture set as the default. I was
heading for being able to build Windows programs on FreeBSD as well.

It is (or at least was) possible to do, but FreeBSD has has the approach
of tools built for the host machine arch or cross-built tools built for
the target architecture.

With support for all the architectures that the GNU tools support built
in by default, FreeBSD makes a great development system for all sorts of
weird (and wonderful?) architectures.

I used to build MVME68K code on FreeBSD. Back in the good old days.

--
John Birrell