On Tue, 29 Jun 1999, Carl Mummert wrote: > >It's not the symlinks, it's the contents of /usr/include/*.h that's the > >problem.
> They are the problem, but they cannot be fixed. Since the GNU C library > is portable to various kernels and hardware platforms, it has to get > its information about the underlying system from somewhere. Now, this is getting nonsensical. First, you tell me that the reason that there are no symlinks is because the details of the underlying system can interfere with the operation of the libc. Now, you tell me that the reason that you can't apply a proper fix the first problem is because sometimes libc has to get information about the underlying system. If you delete the symlinks and replace them with directories containing files that don't have anything to do with the kernel that's running you have eliminated any possibility of libc-based programs getting information about the underlying system. That means that the libc itself must not have access to information about the underlying system on those computers with the symlinks removed. This technique works, in most cases, because the libc doesn't have any business knowing what the kernel innards look like. Since most programs talk to libc rather than using kernel-specific interfaces, it works for most people. Unfortunately, I sometimes do kernel-specific programming and I think that this shows poor design and a complete lack of thought. I honestly expected better of you. (Well, them. I mostly mean the glibc maintainers.) Making my life a little tougher based upon the idea that I'm more able to deal with it than Joe Random Luser is NOT ACCEPTABLE to me. It shouldn't be acceptable to you, either. The files in /usr/include/sys (which, as you say, are the bulk of the problem) have no business referring to any files in /usr/include/linux or /usr/include/asm unless they need things that can change if the kernel changes. The proper approach would be to separate out the libc header stuff that's truly system-dependant (they won't kill libc-based programs because otherwise you'd need a new libc for every different kernel version) and put them in new header files that don't have any libc-killer stuff You can do that without changing the meaning of any of the linux include files if you use the approach outlined by Plauger in the C USER'S JOURNAL several years ago. However, I expect I'm the only one who thinks that's the proper approach so, how's this for a solution: Give the /usr/include/asm and /usr/include/linux directories up as lost causes. Instead, define new directories. Say /usr/include/kernel-asm and /usr/include/kernel-linux. Make THEM symlinks to the appropriate directories in the kernel source tree. I would do this on my own computer, but I don't really get any benefit from it unless everyone else, particularly those who develop modules and whatnot, decides to use the same convention. Therefore, we then attempt to convince people to actually use those directories instead of /usr/include/asm and /usr/include/linux for the good reasons that we've discussed. -- Jonathan Guthrie ([EMAIL PROTECTED]) Brokersys +281-895-8101 http://www.brokersys.com/ 12703 Veterans Memorial #106, Houston, TX 77014, USA
