Breakage with bleeding edge host toolchains (Fedora)

Dan Nicholson dbn.lists at
Tue Feb 27 20:44:15 PST 2007

On 2/27/07, Bryan Kadzban <bryan at> wrote:
> Dan Nicholson wrote:
> > I suppose that would probably work. It opens the door that people
> > would forget to make it executable again.
> Hmm, that could be an issue.  We can put commands into the book to make
> it executable again (in fact I'd say we'd have to, if we want the book
> to be usable ;-)), but there's nothing that would force the user to run
> them.  Problems would likely only show up either when they try to
> chroot, or when they try to compile the first package in chapter 6.

Actually, it's not so bad since you can always run `chmod a+x
/tools/bin/ld' safely. Maybe this is the right way to go. I guess it's
more preference that I like the other way, but this would seem to do
the trick, too.

> >> Or how about $COMPILER_PATH?
> >
> > This is essentially the same as passing -B.
> You're right that the effects are the same, and if there's no objection
> to -B, I'd say use it instead (just because I don't know a ton about gcc
> internals; certainly not as much as Greg).  But COMPILER_PATH might be
> one way to get around the issue of -B not being intended for this, which
> I think was an objection raised earlier.  (But maybe I'm mistaken --
> maybe another workaround that was mentioned wasn't intended to fix this
> issue.  I don't remember the details anymore.)  It would depend on what
> else (if anything) is affected by the flag and the environment variable.

I'm actually starting to come around to COMPILER_PATH. I wonder how
far back in gcc's history it's supported?

As for you not groking gcc internals, Ryan pointed out to me a long
time ago that if you just read gcc.c you can have a pretty good idea
of what's going on. I'm not sure there's much more of the true
internals that we need to be concerned with from a native
bootstrapping perspective (besides all the autofoo).

The objection to -B doesn't actually apply here. What we're doing in
this case is exactly what -B is meant for. Tell gcc that you prefer a
different path when it searches for its subprograms.

The old Ryan/Greg argument has to do with Greg's preference of using
-B/usr/lib/ to force gcc to find the glibc startfiles in /usr/lib.
Ryan didn't agree that this was the proper method since the stated
purpose for -B is what we're talking about here. That's why we still
have *startfile_prefix_spec in the book even though it isn't totally
supported correctly.

For this case, it looks like there's a couple different ways we can
attack this. But I think we agree that this is a good thing to do.
Let's give Matthew and anyone else to chime in.


More information about the lfs-dev mailing list