On 3/16/12 3:22 AM, Bryan Kadzban wrote:
> 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.
And we adjust the toolchain still in chapter 6, using the specs file, so
this knowledge isn't lost.
> 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. :-)
The word revert alone should raise red flags. :) Also, keep in mind that
with the current build method, even after we adjust the toolchain, we
_still_ have to use -B to get the compiler to work properly. I'm not
saying there's something inherently wrong with -B, but I think it shows
that the method is broken - our compiler should be fully configured to
know and find our temporary libc on its own.
> (And I don't know enough about what limits.h is doing to know whether
> that edit is a good one or not.)
This is because gcc always searches its internal fixed headers first -
and those headers will always include a version of limits.h, even if we
aren't running the fixincludes script. If, when building gcc, it finds a
copy of limits.h in its search path, then it will append and prepend to
its limits.h logic to have it include_next the system limits.h
I actually see this as a good thing. GCC is so confined to the sysroot
location that it _can't_ pick up anything from the host, it just adds a
minimal limits.h file instead.
The second pass of gcc (the full one with shared libgcc and c++)
actually needs things defined from libc so you need to do one of two things:
1) Hard code an include to /tools/include/limits.h in gcc's code
2) Do what gcc would have done on the first round if it found the system
limits.h and append and prepend the logic to include_next
Here's the actual code in gcc that does this:
# Test to see whether <limits.h> exists in the system header files.
LIMITS_H_TEST = [ -f $(SYSTEM_HEADER_DIR)/limits.h ]
...and then...
if $(LIMITS_H_TEST) ; then \
cat $(srcdir)/limitx.h $(srcdir)/glimits.h
$(srcdir)/limity.h > tmp-xlimits.h; \
else \
cat $(srcdir)/glimits.h > tmp-xlimits.h; \
fi;
> 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 had this, but can't seem to find the logs at the moment... I'll try to
re-gen and provide an answer shortly.
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
