binutils deps

Robert Connolly robert at linuxfromscratch.org
Mon Jan 24 18:11:07 PST 2005


On January 24, 2005 08:46 pm, Jeremy Utley wrote:
> Robert Connolly wrote:
> >FSF was under a lot of pressure to release 2.15, and it wasn't really
> >finished. They released it too early, or maybe too late. They did it at a
> >time when toolchain features were changing in both gcc and glibc. I expect
> >2.16 to be more usable, but I don't expect it until after gcc4
> > (autumn/winter 2005). FSF Binutils is generally better for us, it gets a
> > better audit than HJL's, but 2.15 is an exception.
> >
> >But anyway, I've had a couple people show me build errors with
> > binutils-pass1 because they didn't have bison installed on their host. It
> > would be prudent to add m4/bison/flex to the deps list.
> >
> >robert
>
> Yes, this should probably be done - could you please open a bugzilla
> entry for this?  However, m4/bison/flex are also required for the FSF
> 2.15 release, so it's a dep anyway you look at it.
>
> I happen to disagree with your preference of FSF over HJL's code.  HJL's
> releases are much more widely tested on the linux platform than FSF
> releases, considering the fact that every linux distro that I'm aware of
> uses HJL's releases.  If we were doing something non-linux, then I might
> feel differently.
>
> -J-

Debian is using FSF Binutils. But I agree, everyone else uses HJL. HJL's might 
be used more in Linux, but he's maintaining his branch all by himself, and 
aside from testers no one really double checks his work, like they do with 
the FSF branch. The non-linux-elf platforms use much of the same code, the 
bsd's especially tend to double check the FSF's branch. HJL's branch is more 
prone to blunders. I don't mean any offense to HJ Lu, but his branch is 
_beta_, and as such has more bugs, as well as the newest features. The 2.16 
FSF release should be stable for gcc-3.4 and glibc-2.3.4, and so I think it 
will be a good choice for -stable. The beta branch will go onward to new 
-unstable things.

robert



More information about the lfs-dev mailing list