Breakage with bleeding edge host toolchains (Fedora)
dbn.lists at gmail.com
Tue Feb 27 20:44:15 PST 2007
On 2/27/07, Bryan Kadzban <bryan at kadzban.is-a-geek.net> 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
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