On 14/07/10 20:18, Dan McGhee wrote: > In addition to the testing failures I've documented in another thread, > I've also had an installation failure with GlibC-2.11.2. I know the > cause though. It's a result of using the More Control and Package User > package management system. I've encountered similar things in my > previous builds, but this one generated a question. > > This install fails with the message: >> /tools/bin/install: cannot remove `/usr/include/scsi/scsi.h': >> Operation not permitted > > The reason is that in this package management system the sticky bit is > set and one package user cannot remove or alter a file installed by > another package user. In this case the user "linux-2.6.34-headers" > installed scsi.h. User "glibc-2.11.2" wants to remove this file and > replace it with one of it's own. > > The GlibC install wants to install sg.h, scsi.h and scsi_ioctl.h in > /usr/include/scsi. There are two ways in which to get the install > process to proceed. The first is for me to manually remove scsi.h and > let glibc do it's thing. The other is for me to delete the installation > of scsi.h from the makefile. This is the only instance of this type of > conflict between glibc and linux headers. > > So, my question is: Does it make a difference which header file is in > /usr/include/scsi or is one better than the other? The answer to this > question will dictate which of the two actions I will take. > If you don't replace the kernel's /usr/include/scsi/scsi.h with hte one from glibc then you will get build failures later on. I think it was udev which failed? Some other things in BLFS (cdrtools?) also fail. Just do what a normal LFS install would do and install the glibc versions.
Andy -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
