Greg Schafer wrote: > The sysroot infrastructure is clearly designed for a $SYSROOT/usr > layout which we DO NOT HAVE in the temporary phase!
Yeah, that's why my previous message was more or less comparing it to a DESTDIR type installation. That may not be accurate, but it seems vaguely similar. I'm not sure that it's a critical failure of the sysroot setup, but it does raise at least one red flag. (OTOH if Fedora ends up pushing the UsrMove stuff far enough, stuff like this will end up not being detectable, either. Hmm.) > Here is an earlier posting/thread which explains it in a lot more > detail: > > http://linuxfromscratch.org/pipermail/lfs-dev/2009-January/062541.html As for specific points in that thread, my (again potentially not very useful) opinion: Removing the need for adjusting the toolchain does seem to hurt teaching; we're using some magic flags instead of editing the specs file. (OTOH the specs file is now more of a builtin thing in the gcc driver. I do still think it's useful to know about it, though.) We're still rebuilding ld, though. That being said, is editing the pass1 gcc sources with sed (editing the STANDARD_STARTFILE_PREFIX_? values, and the header directories) better, or worse, than reverting upstream changes in pass2? I don't suppose there's a way to avoid both; that'd be too easy. :-) (And I don't know enough about what limits.h is doing to know whether that edit is a good one or not.) As for searching the host, I'm not entirely sure which way to go there. What does the current-book pass1 gcc binary say, if you do something like: echo 'main(){}' | /whatever/gcc -v -xc -Wl,-verbose - for the include path order and the linker SEARCH_DIR()s? Where does it find crt1.o, libgcc, libc, ld-linux.so.2 (or the 64-bit ld.so), etc.? How does that compare to the sysroot pass1 build? (I assume there's no change in the chapter 6 build, or ICA should pick it up. The pass2 build is not likely to be that different, although that might be interesting to double check as well.) I don't see a lot of other specific objections, though I don't have a lot of context, so I may not be giving some of the general statements as much weight as they need. > And while we are on the subject of getting up-to-speed with toolchain > matters, it looks like GCC 4.7 is the start of the "transition to > build GCC with g++". This could have massive implications for us > considering we dropped the GCC bootstrap when we brought in the cross > stuff: I haven't figured out how the bootstrap (assuming you mean --disable-bootstrap) interacts with g++, but yes, I can see gold and/or gcc-with-g++ requiring a bunch of changes. *Hopefully* those will be obvious errors, and not silently miscompiling something, because it's obviously a lot harder to fix the latter. > On the plus side, there is a stack of work going into Glibc at the > moment. A lot of it appears to have originated in the eGlibc project > to ease cross building and bootstrapping etc. I'm not sure how it > happened, but it seems Ulrich doesn't exert the same control he once > had. I also noticed that on the ::gets() breakage thread. (http://sourceware.org/bugzilla/show_bug.cgi?id=13566) OTOH our glibc instructions aren't that complicated, either. It's probably too much to hope for that the bootstrapping mindset takes root in upstream gcc as well, but I'm going to hope for it anyway. This might get better.
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
