On 07/14/2010 04:50 PM, Andrew Benton wrote: > 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. > > I just changed the name of the kernel header and now GlibC and me play well together.
I want to thank everyone you responded to this post--tongue in cheek or not. It is true that I wouldn't have encountered this if I hadn't been using the More Control package management. This situation is one of the things it's designed to identify. And I really learned a lot especially about which headers go where and how things link to them. So, thanks to all again. I did have occasion to use a find | cpio combo that I really like. It might be useful to others. I'll start another thread with it so that the command itself is not hidden and obscure during a search. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
