Glibc-2.5 build errors (limits.h etc)

Bruce Dubbs bruce.dubbs at gmail.com
Sat Feb 10 11:45:52 PST 2007


Chris Staub wrote:

> Yes, but in general it doesn't matter *where* you build stuff, it will 
> still work fine.
> 
> However, this does seem to be an exception in the case of Glibc 
> 2.5...I've been testing it myself, and I get a build failure due to the 
> same problem, as it keeps complaining that 
> "/mnt/lfs/tools/glibc-build/../include/[headerfile].h and 
> /tools/include/[headerfile].h are the same file".
> 
> mv -f /mnt/lfs/tools/glibc-build/s-proto.T 
> /mnt/lfs/tools/glibc-build/s-proto.d
> make[2]: Leaving directory `/mnt/lfs/tools/glibc-2.5/signal'
> make[2]: Entering directory `/mnt/lfs/tools/glibc-2.5/signal'
> /bin/install -c -m 644 
> /mnt/lfs/tools/glibc-build/../include/linux/limits.h 
> /tools/include/linux/limits.h
> /bin/install: `/mnt/lfs/tools/glibc-build/../include/linux/limits.h' and 
> `/tools/include/linux/limits.h' are the same file

I've been trying to understand what is going on in this thread, but am
having difficulty.  from what I can see the system is trying to install

/mnt/lfs/tools/glibc-build/../include/linux/limits.h  which is, for
clarity  /mnt/lfs/tools/include/linux/limits.h

as

/tools/include/linux/limits.h

Our problem is that we have a symlink from /tools to /mnt/lfs/tools/

My question is: Why does the package try to install something *from* a
location that is outside its own files.  Its own files reside on, in
this case,

{/mnt/lfs}/tools/glibc-build/  and
{/mnt/lfs}/tools/glibc-$glibc-version

but it is installing *from*

{/mnt/lfs}/tools/linux/

What am I missing?

  -- Bruce



More information about the lfs-dev mailing list