Re: Ch. 6 GlibC Install Failure from Package Management--Which headers to use [Solved]
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
Ch. 6 GlibC Install Failure from Package Management--Which headers to use
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. Thanks, Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ch. 6 GlibC Install Failure from Package Management--Which headers to use
On 14 July 2010 20:18, Dan McGhee beesn...@grm.net wrote: 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 weren't using the package users hint, the problem would not arise. Therefore we can assume that allowing the kernel's headers to be installed is the well-tested choice. In the sense that LFS is your distro, your rules you are, of course, free to do things differently. I've no idea *which* packages in a fully-built system use these particular headers (probably, not much in LFS itself). Taking a look at the two sets of headers, they aren't *that* different, so it is possible that both *might* work. ĸen -- After tragedy, and farce, OMG poneys! -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ch. 6 GlibC Install Failure from Package Management--Which headers to use
On 07/14/2010 02:33 PM, Ken Moffat wrote: If you weren't using the package users hint, the problem would not arise. Therefore we can assume that allowing the kernel's headers to be installed is the well-tested choice. You are absolutely right, but I would not characterize it as a problem, but something to be considered and about which to make a decision. In fact, it's the reason I posted. Using only the instructions in the LFS book, this header file would be replaced three times--which may be the answer to the questions. It's first installed by the linux ABI headers in Ch. 6 and then by GlibC in Ch. 6. Then it would be replaced again when the kernel was compiled and installed. So maybe the answer is just to use the kernel version. In the sense that LFS is your distro, your rules you are, of course, free to do things differently. I've no idea *which* packages in a fully-built system use these particular headers (probably, not much in LFS itself). Taking a look at the two sets of headers, they aren't *that* different, so it is possible that both *might* work. Duh! Occam's Razor again!!! My bad. I ran diff on the two files and if volume is the measure, there's a whole lot more to the kernelt version. But your suggestion is great. I could patch one of the files, and, if it were overwritten by the kernel installation, replace it with the patched version. Thanks, Ken Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ch. 6 GlibC Install Failure from Package Management--Which headers to use
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
Re: Ch. 6 GlibC Install Failure from Package Management--Which headers to use
On 14/07/10 21:10, Dan McGhee wrote: On 07/14/2010 02:33 PM, Ken Moffat wrote: If you weren't using the package users hint, the problem would not arise. Therefore we can assume that allowing the kernel's headers to be installed is the well-tested choice. You are absolutely right, but I would not characterize it as a problem, but something to be considered and about which to make a decision. In fact, it's the reason I posted. Using only the instructions in the LFS book, this header file would be replaced three times--which may be the answer to the questions. It's first installed by the linux ABI headers in Ch. 6 and then by GlibC in Ch. 6. Then it would be replaced again when the kernel was compiled and installed. No, when you install the kernel you just install the kernel. You don't overwrite the headers in /usr/include. Here be monsters! Andy -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ch. 6 GlibC Install Failure from Package Management--Which headers to use
On 07/14/2010 04:50 PM, Andrew Benton wrote: 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. Thanks for the tip, Andy. I'm pretty sure you use More Control too. It helps to have someone else's experience. But.. Guess who pooched himself. Before I reinstalled glibc I mv scsi.h scsi.h-orig to let glibc do its thing. Then I had a complete loss of reality accident--that I discovered when I checked after reading your post--and eliminated scsi.h from the glibc makefile. As Ken might say *rats*. Maybe I'd better take time off this build to go outside where it's 99 degrees F with 94% humidity and really fry my brains. Another guess. Guess who gets to rebuild glibc with his newly edited script that solved the test failure problem? Argh! I hope everyone who reads this is getting a good laugh. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ch. 6 GlibC Install Failure from Package Management--Which headers to use
On Wednesday 14 July 2010 18:07:13 Dan McGhee wrote: I hope everyone who reads this is getting a good laugh. No, just chuckling and nodding knowingly. As I hobble around on my bullet-riddled feet. Need the t-shirt? As long as *you* are laughing, all is well. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ch. 6 GlibC Install Failure from Package Management--Which headers to use
On 07/14/2010 05:23 PM, Neal Murphy wrote: On Wednesday 14 July 2010 18:07:13 Dan McGhee wrote: I hope everyone who reads this is getting a good laugh. No, just chuckling and nodding knowingly. As I hobble around on my bullet-riddled feet. Need the t-shirt? As long as *you* are laughing, all is well. I am now. :) -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ch. 6 GlibC Install Failure from Package Management--Which headers to use
Dan McGhee wrote:
You are absolutely right, but I would not characterize it as a problem,
but something to be considered and about which to make a decision. In
fact, it's the reason I posted. Using only the instructions in the LFS
book, this header file would be replaced three times--which may be the
answer to the questions. It's first installed by the linux ABI headers
in Ch. 6 and then by GlibC in Ch. 6. Then it would be replaced again
when the kernel was compiled and installed. So maybe the answer is just
to use the kernel version.
I don't think so. The header needs to describe the API actually
implemented, which is the one provided by GLIBC. I would not install
the stuff the kernel uses, since that's not what your applications
(when you build some later) will be linked against. They'll link
against GLIBC, and that's what I'd use.
Mike
--
p=p=%c%s%c;main(){printf(p,34,p,34);};main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
