Ambrose Li wrote:
On Tue, Jan 27, 2004 at 10:06:46AM -0500, Greg Wooledge wrote:True -- *but*, it must be pointed out that this is historic! In a modern GNU/Linux distribution, /usr/include/linux should *not* be a symlink to anything at all. It should be a plain directory containing the kernel header files with which the GNU libc was built.If this is true, I must respectfully point out that the real problem is libc6. I upgraded my system to libc6 by hand, and I *never* saw any advice (or "instruction" should be a better word) to make /usr/include/linux a real directory, nor any advice to keep the libc6-compile-time kernel header files anywhere, nor any advice where to put the current kernel header files. Actually that info is in the Linux file standard, which has been available for some years. There are some distributions which don't follow that, all I can say is "there is a standard." Without getting into a flame war, he is saying that and then depending on installs to behave in some predictable manner which seems to be blaming Linux (which does have a standard) rather than doing defensive programming.If such a drastic change in convention had taken place and I have never read about it when I did my upgrade (which was not very long ago -- I put off upgrading to libc6 until very recently, and I did google for advice for fear of breaking my system), then I have to agree with Joerg that Linux is being very inconsistent, but I will say that the greatest problem is not in the kernel, but in libc6. This also implies that cross compilation seems to need source edits, since having /usr/src/linux is optional and would point to the running kernel on the source system if present. It would make life easier for both Joerg and users to state that if the /usr/include/linux headers are not correct for the kernel on which the application will run, then the user must provide the information. As an example: CDRTOOLS_KERNEL_INC=/root/my_2.6_includes make Joerg is willing to put the responsibility for reading the multitude of README files on the user; many times he will point out that someone didn't follow README.multi or similar, and I think he is right. But he doesn't put the responsibility on the user to provide include pointers, and I think that's wrong. cdrtools should use /usr/include/linux unless told otherwise. Trying to guess which headers to use frustrates both the developer and the users, as the endless threads show. Another approach would be to require the user to create a symlink to the includes in the cdrtools directory. And just don't compile until that's done. It not only gives the user a way to get it right, it forces the user to think, which is probably a good thing. Odd distributions are a fact of life, and old distributions which have been updated are, too. I think we have proven that the build system can't correct for all the things people do, so why not make the user supply the information? -- bill davidsen <davidsen@tmr.com> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 |