Glibc-2.5 build errors (limits.h etc)

Dan Nicholson dbn.lists at gmail.com
Sat Feb 10 09:24:46 PST 2007


On 2/10/07, Chris Staub <chris at beaker67.com> 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



More information about the lfs-dev mailing list