David Z. Maze <[EMAIL PROTECTED]> wrote: > Are you trying to build a kernel module? If so, are you explicitly > giving it a path to the kernel headers, or are you letting it default > to /usr/include/linux? The stuff in /usr/include/linux is almost > certainly wrong and has a ~0% chance of corresponding to the kernel > you're actually using; see /usr/share/doc/libc6/README.Debian.gz for > details of what's going on, and why.
Actually, no. My applications are strictly user-land. There is only one explicit reference to a "linux/" header (linux/pci.h) anywhere in the code and that is an error (it should not be there). The compile error I posted was just an example; there were may others of a similarly extreme nature. Sadly I cannot recreate them as I have in the course of the day tried removing a few things and reverting to stable. I have ended up with no development stuff at all. I baulked at removing libc6 as a big long list of dependencies was presented, along with an indication that it would be a bad idea. However, I get the feeling I need to remove or replace libc6 as dselect refuses to do anything useful as long as a conflict exists between libc6-dev (currently not installed) depending upon libc6 2.1.3-18 (2.2.3-5 installed). Is there an easy way out of this? I was just considering playing with dpkg and its force-downgrade option, fully expecting that this would be followed shortly after by a fresh installaion. Any advice? I guess this will teach me not to touch anything marked "test" or "unstable" if I don't know exactly what I'm doing. Thanks for taking the trouble to reply. Regards -- William Morris [EMAIL PROTECTED]