On 2/27/07, Bryan Kadzban <[EMAIL PROTECTED]> 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. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
