Glibc-2.5 build errors (limits.h etc)

Chris Staub chris at beaker67.com
Sat Feb 10 08:00:21 PST 2007


Matthew Burgess wrote:
> On Saturday 10 February 2007 06:23, Dan Winkler wrote:
> 
>> i unpack the package in /mnt/lfs/tools then follow the instructions.
> 
> Why?  It's recommended that all packages should live in /sources and be 
> unpacked there.  See 3.1: Introduction
> 
> "Downloaded packages and patches will need to be stored somewhere that is 
> conveniently available throughout the entire build. A working directory is 
> also required to unpack the sources and build them. $LFS/sources can be used 
> both as the place to store the tarballs and patches and as a working 
> directory."
> 
> Regards,
> 
> Matt.

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
/bin/install -c -m 644 
/mnt/lfs/tools/glibc-build/../include/asm/unistd.h 
/tools/include/asm/unistd.h
/bin/install: `/mnt/lfs/tools/glibc-build/../include/asm/unistd.h' and 
`/tools/include/asm/unistd.h' are the same file
.././scripts/mkinstalldirs /mnt/lfs/tools/glibc-build/signal
mkdir /mnt/lfs/tools/glibc-build/signal

Compare that with the same bit from a compile elsewhere...

mv -f /home/lfs/sources/glibc-build/s-proto.T 
/home/lfs/sources/glibc-build/s-pr
oto.d
make[2]: Leaving directory `/home/lfs/sources/glibc-2.5/signal'
make[2]: Entering directory `/home/lfs/sources/glibc-2.5/signal'
.././scripts/mkinstalldirs /home/lfs/sources/glibc-build/signal
mkdir /home/lfs/sources/glibc-build/signal


Hmmm, I think I may have found something here. I created an "include" 
directory in /home/lfs/sources and copied the contents of /tools/include 
there. Then I unpacked Glibc in /home/lfs/sources and started building. 
I'm seeing lines this this in the compile process...

/bin/install -c -m 644 
/home/lfs/sources/glibc-build/../include/linux/limits.h /
tools/include/linux/limits.h
/bin/install -c -m 644 
/home/lfs/sources/glibc-build/../include/asm/unistd.h /to
ols/include/asm/unistd.h
/bin/install -c -m 644 
/home/lfs/sources/glibc-build/../include/linux/param.h /t
ools/include/linux/param.h
/bin/install -c -m 644 
/home/lfs/sources/glibc-build/../include/asm/param.h /too
ls/include/asm/param.h
/bin/install -c -m 644 
/home/lfs/sources/glibc-build/../include/asm/socket.h /to
ols/include/asm/socket.h
/bin/install -c -m 644 
/home/lfs/sources/glibc-build/../include/asm/sockios.h /t
ools/include/asm/sockios.h

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...



More information about the lfs-dev mailing list