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
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
