On 2/10/07, Chris Staub <[EMAIL PROTECTED]> wrote:
>
> Apparently, if there is an "include" dir one level up from the Glibc
> build dir, it automatically copies headers from there into the default
> include dir. Obviously, this means that if you build Glibc in /tools, it
> tries to copy from "glibc-build/../include" to "/tools/include" and in
> that case they are the same file. Perhaps someone more knowledgeable
> than I can dig more into the code to see why this happens, and whether
> it's *supposed* to do that...
Nice job figuring this out, Chris. It's kind of hard to tell what's
going on since the Glibc build files are so unique. This might be
wrong because I really don't understand how the '$(..)' variable is
getting set, but I think this is the make target that's causing
problems (in Makerules):
# This implicit rule installs headers from the source directory.
# It may be ignored in preference to rules from sysd-rules to find
# headers in the sysdeps tree.
...
$(inst_includedir)/%.h: $(..)include/%.h $(+force)
$(do-install)
What should be the warning, though? "Don't build in /tools"? "Don't
build in a directory that has an include/ directory"? Maybe just "Be
sure to build in a dedicated source directory separate from the
installed files"?
Maybe we should just ignore the problem and tell people they can deal
with the breakage if they don't build in /sources.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
