Re: /usr/include/asm/mpspec.h
On Wed, Dec 17, 2003 at 01:04:15AM +0530, Rajkumar S wrote:
> While investigating a compilation problem of samhain, I found that the
> /usr/include/asm/mpspec.h is totally different from what is provided by
> RH or the stock kernel.
It's from the 2.6 kernel, but that shouldn't matter because
/usr/include/asm is private to glibc. (In particular, it doesn't matter
that /usr/include/{asm,linux} is 2.6 while you're running 2.4.)
Userspace applications should never include or ;
they should copy the bits of kernel interface they need instead. It's
not very nice, but it's what you have to do right now.
This is a bug in samhain.
That said, it could be worked around in linux-kernel-headers, so you
could file a lower-severity bug against that.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
/usr/include/asm/mpspec.h
Hi, While investigating a compilation problem of samhain, I found that the /usr/include/asm/mpspec.h is totally different from what is provided by RH or the stock kernel. I am not knowledgeable enough to understand the differences, but debian version includes 3 files in it #include #include #include of which mach_mpspec.h is missing. agni:~/samhain-1.7.11# find /usr/include/ -name mach_mpspec.h /usr/include/asm/mach-generic/mach_mpspec.h /usr/include/asm/mach-default/mach_mpspec.h /usr/include/asm/mach-bigsmp/mach_mpspec.h /usr/include/asm/mach-es7000/mach_mpspec.h /usr/include/asm/mach-numaq/mach_mpspec.h /usr/include/asm/mach-summit/mach_mpspec.h samhain compilation fails due to this. I guess it is a case of a missing symlink, so my questions are, why debian version is different and how to rectify the situation? the samhain compilation error is attached. i am using stock Sarge, uname -a Linux agni 2.4.22-1-386 #9 Sat Oct 4 14:30:39 EST 2003 i586 GNU/Linux Kernel packages are: ii kernel-headers-2.4.22-1 2.4.22-3 ii kernel-headers-2.4.22-1-386 2.4.22-3 ii kernel-image-2.4.22-1-3862.4.22-3 ii linux-kernel-headers 2.5.999-test7-bk-9 raj -- compilation error: ./encode 0 sh_unix.c --> x_sh_unix.c gcc -DHAVE_CONFIG_H -I. -I. -O2 -Wall -W -fno-strength-reduce -fno-omit-fram e-pointer -DSH_STANDALONE -o sh_unix.o -c x_sh_unix.c In file included from /usr/include/linux/blockgroup_lock.h:8, from /usr/include/linux/ext2_fs_sb.h:19, from /usr/include/linux/ext2_fs.h:20, from x_sh_unix.c:2124: /usr/include/linux/spinlock.h: In function `bit_spin_lock': /usr/include/linux/spinlock.h:413: error: invalid type argument of `->' /usr/include/linux/spinlock.h: In function `bit_spin_trylock': /usr/include/linux/spinlock.h:430: error: invalid type argument of `->' /usr/include/linux/spinlock.h:433: error: invalid type argument of `->' /usr/include/linux/spinlock.h:433: error: `TIF_NEED_RESCHED' undeclared (first u se in this function) /usr/include/linux/spinlock.h:433: error: (Each undeclared identifier is reporte d only once /usr/include/linux/spinlock.h:433: error: for each function it appears in.) In file included from /usr/include/linux/blockgroup_lock.h:8, from /usr/include/linux/ext2_fs_sb.h:19, from /usr/include/linux/ext2_fs.h:20, from x_sh_unix.c:2124: /usr/include/linux/spinlock.h: In function `bit_spin_unlock': /usr/include/linux/spinlock.h:451: error: invalid type argument of `->' /usr/include/linux/spinlock.h:451: error: `TIF_NEED_RESCHED' undeclared (first u se in this function) In file included from /usr/include/linux/cpumask.h:8, from /usr/include/asm/smp.h:11, from /usr/include/linux/smp.h:17, from /usr/include/linux/percpu_counter.h:9, from /usr/include/linux/ext2_fs_sb.h:20, from /usr/include/linux/ext2_fs.h:20, from x_sh_unix.c:2124: /usr/include/linux/bitmap.h: In function `bitmap_empty': /usr/include/linux/bitmap.h:15: error: `BITS_PER_LONG' undeclared (first use in this function) /usr/include/linux/bitmap.h: In function `bitmap_full': /usr/include/linux/bitmap.h:29: error: `BITS_PER_LONG' undeclared (first use in this function) /usr/include/linux/bitmap.h: In function `bitmap_equal': /usr/include/linux/bitmap.h:44: error: `BITS_PER_LONG' undeclared (first use in this function) /usr/include/linux/bitmap.h: In function `bitmap_shift_right': /usr/include/linux/bitmap.h:85: error: `__shr_tmp' undeclared (first use in this function) /usr/include/linux/bitmap.h: In function `bitmap_shift_left': /usr/include/linux/bitmap.h:98: error: `__shl_tmp' undeclared (first use in this function) /usr/include/linux/bitmap.h: In function `bitmap_weight': /usr/include/linux/bitmap.h:144: error: `BITS_PER_LONG' undeclared (first use in this function) In file included from /usr/include/asm/smp.h:11, from /usr/include/linux/smp.h:17, from /usr/include/linux/percpu_counter.h:9, from /usr/include/linux/ext2_fs_sb.h:20, from /usr/include/linux/ext2_fs.h:20, from x_sh_unix.c:2124: /usr/include/linux/cpumask.h: At top level: /usr/include/linux/cpumask.h:15: error: variable-size type declared outside of a ny function In file included from /usr/include/asm/smp.h:11, from /usr/include/linux/smp.h:17, from /usr/include/linux/percpu_counter.h:9, from /usr/include/linux/ext2_fs_sb.h:20, from /usr/include/linux/ext2_fs.h:20, from x_sh_unix.c:2124: /usr/include/linux/cpumask.h: In function `
Re: /usr/include/linux and /usr/include/asm?
On Tue, 29 Jun 1999, Evan Van Dyke wrote: > *SNIP* > > 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. > If you havn't read the letter by Linux Torvalds that was referred to under > this thread within the last few days, I suggest that you do so. I read it. In fact, the message that you quote was primarily in response to that message. I UNDERSTAND the problem. I solved similar problems back 15 years ago when I first started debugging clibs. It's the solution that I find lacking. Too bad you didn't quote the part of my message that was really important: Making my life tougher because it's easier for me to deal with it than Joe Random Luser is NOT AN ACCEPTABLE SOLUTION! Yes, I can deal with it Joe Random Luser, but I shouldn't have to. > The obvious choice seems to be /usr/src/linux/include/linux and > /usr/src/linux/include/asmas that is where most people store their > kernel source. Why clutter up /usr/include more with kernel-specific > headers? The entire point is that the /usr/include/* headers should be > kernel-independant after all. Why is that the point? If that's the point, it's a damn stupid one. Look, header files go under /usr/include and /usr/local/include. Since the header files that are kernel specific aren't local to the system, they should be accessible under /usr/include. I should be able to refer to them like that. THAT is what is obvious to me. Why clutter up /usr/include with directories containing kernel-specific headers? Well, why clutter it up with omniORB and ggi and php3? Because /usr/include and the directories underneath are where header files GO, aren't they? Having two sets of files with identical names and nearly identical contents just galls me. What do I care what kernel the glibc maintainer built libc.so.6 on? Why should I keep those files around? The real issue is one that I talked about in my original message: idempotence. While I agree that libc has to know about the kernel calls so that it can wrap them in C-standard functions, it is apparent that glibc, at least, knows far more about the internals of the kernel than is good for it. It is essential that a given version of glibc be able to run on newer kernel versions and on patched kernels. That requires careful design and some foresight, which appears to be lacking in this case. Let's take an example or two from the message from Linus Torvalds: The use of the NR_OPEN constant. The kernel (apparently---I just skimmed over it) uses NR_OPEN to set how many file handles any given task must have. That is, it allocates an array of NR_OPEN "struct file *" for each task that is forked. (The code is in kernel/fork.c, if you have a mind.) Why does glibc refer to this constant anywhere? The number of files that the kernel allows to be opened doesn't necessarily have anything to do with the number of files glibc allows you to open. I suppose that glibc might put an array of size NR_OPEN in order to hold the file handles, but that's dumb. The ISO C standard says that the constant that defines the maximum number of open files is FOPEN_MAX, and it is far smarter to put your file handle in the FILE struct and declare your FILE array to be of size FOPEN_MAX. #define FOPEN_MAX to be the same as NR_OPEN? Use the same sigset_t for both glibc and the Linux kernel? Yes, you COULD do that, but those things don't necessarily have anything to do with each other, and it is poor practice to use the same abstraction to refer to unrelated things even if they happen to be the same at some point. libc abstractions, what most programs use, are NEVER required to be the same as the kernel abstractions. While I agree that you can work around the problem by requiring that /usr/include/asm and /usr/include/linux be the contents of the directories /usr/src/linux/include/asm and /usr/src/linux/include/linux on the system used by the builder of the glibc and by requiring that the kernel source must ALWAYS be in /usr/src/linux, but that is not the correct solution. That is a massive kluge needed because people can't seem to
Re: /usr/include/linux and /usr/include/asm?
In article <[EMAIL PROTECTED]>, Jonathan Guthrie <[EMAIL PROTECTED]> wrote: >Now, this is getting nonsensical. First, you tell me that the reason that [rant deleted] Why can't you simply use -I/usr/src/linux/include if you need those specific kernel includes. Mike. -- Beware of Programmers who carry screwdrivers.
Re: /usr/include/linux and /usr/include/asm?
Jonathan Guthrie wrote: *SNIP* > 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. If you havn't read the letter by Linux Torvalds that was referred to under this thread within the last few days, I suggest that you do so. In a quick summary: Yes, /usr/include/linux;/usr/include/asm should include kernel- independant information for a variety of reasons that he spells out. Eventually, the other distributions should do the same thing, as it is a glibc thing. Debian was just the first to jump on the bandwagon. Programs that need to be kernel specific should find the kernel headers elsewhere. The obvious choice seems to be /usr/src/linux/include/linux and /usr/src/linux/include/asmas that is where most people store their kernel source. Why clutter up /usr/include more with kernel-specific headers? The entire point is that the /usr/include/* headers should be kernel-independant after all. --Evan
Re: /usr/include/linux and /usr/include/asm?
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
Re: /usr/include/linux and /usr/include/asm?
>I would have thought that someone would have figured out by now that >/usr/include/linux (at the very least) should reflect the status of the >kernel so that kernel-specific stuff can be done and that NOTHING in the >library or in the include files associated with that library should depend >upon the kernel-specific files. > >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. Back when we had our very own private C library, we could get away with not separating the user-visible stuff from the kernel-only stuff. But when we start using portable libraries, we have to worry about what is used by normal programmers, and what is used only inside the kernel. find /usr/include -type f | xargs grep 'include.*
Re: (vmware) /usr/include/linux and /usr/include/asm?
My bad. the install.pl, IIRC, suggests unpacking vmnet-only.tar and/or vmmon-only.tar and making the modules by hand if it can't autobuild them. You'll get vmnet-only/Makefile and vmmon-only/Makefile. Again, IIRC. My vmware box is currently in M$ mode so I can play a game. :> On Mon, 28 Jun 1999, Bob Nielsen wrote: > I just looked in vmware-distrib and there ISN'T any Makefile (?). It > looks like install.pl handles it (somehow, it's beyond my grasp of > perl). > > Bob > > On Mon, Jun 28, 1999 at 06:00:50PM -0700, [EMAIL PROTECTED] wrote: > > > > What I've done is put my kernel source's include path in the vmware > > Makefile's include path (FI -I/usr/src/linux-2.3.6/include) and it has > > worked fine for me. > > > > I've also compiled the modules (and my kernel) with egcs (I'm running > > Slink - have had troubles upgrading to Potato; wanted to see what USB > > stuff breaks, if any) and -mpentium, and only have framebuffer conflicts > > so far. > > > > On Mon, 28 Jun 1999, Bob Nielsen wrote: > > > > > On Mon, Jun 28, 1999 at 11:24:55AM -0400, Paul D. Smith wrote: > > > > I tried to install vmware over the weekend and it wanted to compile a > > > > kernel module for my 2.2.10 kernel. It complained because my linux > > > > kernel header version was still 2.2.9. I looked and sure enough, > > > > /usr/include/linux and /usr/include/asm were both real directories with > > > > real files. > > > > > > > > Aren't these typically supposed to be symlinks to /usr/src/linux/...? > > > > > > > > Also, how did the headers there get up to 2.2.9? I haven't done > > > > anything fancy to copy headers into those directories, and I've been > > > > downloading kernel patches from www.linuxhq.com etc, not the Debian > > > > packages. Does the normal kernel build usually install these? I wonder > > > > why it didn't for 2.2.10? > > > > > > In Debian, the headers in /usr/include/linux and /usr/include/asm are > > > not symlinks to the kernel source, but are supplied by libc6-dev. As > > > this is periodically upgraded, they may be based on newer kernels--the > > > current potato version comes from 2.2.9. > > > > > > What I did to compile the vmware modules is to mv /usr/lib/linux to some > > > other location and replace it with a symlink to the headers in my 2.2.10 > > > kernel source. You can probably use symlinks all the time, but you > > > should read /usr/doc/libc6-dev/FAQ.Debian.gz to understand the rationale > > > as to why the headers are packaged this way. > > > > > > Bob > > > > > > -- > > > Bob Nielsen Internet: [EMAIL PROTECTED] > > > Tucson, AZ AMPRnet: [EMAIL PROTECTED] > > > DM42nh http://www.primenet.com/~nielsen > > > > > > > > > -- > > > Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] < /dev/null > > > > > > > -- > Bob Nielsen Internet: [EMAIL PROTECTED] > Tucson, AZ AMPRnet: [EMAIL PROTECTED] > DM42nh http://www.primenet.com/~nielsen >
Re: (vmware) /usr/include/linux and /usr/include/asm?
I just looked in vmware-distrib and there ISN'T any Makefile (?). It looks like install.pl handles it (somehow, it's beyond my grasp of perl). Bob On Mon, Jun 28, 1999 at 06:00:50PM -0700, [EMAIL PROTECTED] wrote: > > What I've done is put my kernel source's include path in the vmware > Makefile's include path (FI -I/usr/src/linux-2.3.6/include) and it has > worked fine for me. > > I've also compiled the modules (and my kernel) with egcs (I'm running > Slink - have had troubles upgrading to Potato; wanted to see what USB > stuff breaks, if any) and -mpentium, and only have framebuffer conflicts > so far. > > On Mon, 28 Jun 1999, Bob Nielsen wrote: > > > On Mon, Jun 28, 1999 at 11:24:55AM -0400, Paul D. Smith wrote: > > > I tried to install vmware over the weekend and it wanted to compile a > > > kernel module for my 2.2.10 kernel. It complained because my linux > > > kernel header version was still 2.2.9. I looked and sure enough, > > > /usr/include/linux and /usr/include/asm were both real directories with > > > real files. > > > > > > Aren't these typically supposed to be symlinks to /usr/src/linux/...? > > > > > > Also, how did the headers there get up to 2.2.9? I haven't done > > > anything fancy to copy headers into those directories, and I've been > > > downloading kernel patches from www.linuxhq.com etc, not the Debian > > > packages. Does the normal kernel build usually install these? I wonder > > > why it didn't for 2.2.10? > > > > In Debian, the headers in /usr/include/linux and /usr/include/asm are > > not symlinks to the kernel source, but are supplied by libc6-dev. As > > this is periodically upgraded, they may be based on newer kernels--the > > current potato version comes from 2.2.9. > > > > What I did to compile the vmware modules is to mv /usr/lib/linux to some > > other location and replace it with a symlink to the headers in my 2.2.10 > > kernel source. You can probably use symlinks all the time, but you > > should read /usr/doc/libc6-dev/FAQ.Debian.gz to understand the rationale > > as to why the headers are packaged this way. > > > > Bob > > > > -- > > Bob Nielsen Internet: [EMAIL PROTECTED] > > Tucson, AZ AMPRnet: [EMAIL PROTECTED] > > DM42nh http://www.primenet.com/~nielsen > > > > > > -- > > Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] < /dev/null > > > -- Bob Nielsen Internet: [EMAIL PROTECTED] Tucson, AZ AMPRnet: [EMAIL PROTECTED] DM42nh http://www.primenet.com/~nielsen
Re: (vmware) /usr/include/linux and /usr/include/asm?
What I've done is put my kernel source's include path in the vmware Makefile's include path (FI -I/usr/src/linux-2.3.6/include) and it has worked fine for me. I've also compiled the modules (and my kernel) with egcs (I'm running Slink - have had troubles upgrading to Potato; wanted to see what USB stuff breaks, if any) and -mpentium, and only have framebuffer conflicts so far. On Mon, 28 Jun 1999, Bob Nielsen wrote: > On Mon, Jun 28, 1999 at 11:24:55AM -0400, Paul D. Smith wrote: > > I tried to install vmware over the weekend and it wanted to compile a > > kernel module for my 2.2.10 kernel. It complained because my linux > > kernel header version was still 2.2.9. I looked and sure enough, > > /usr/include/linux and /usr/include/asm were both real directories with > > real files. > > > > Aren't these typically supposed to be symlinks to /usr/src/linux/...? > > > > Also, how did the headers there get up to 2.2.9? I haven't done > > anything fancy to copy headers into those directories, and I've been > > downloading kernel patches from www.linuxhq.com etc, not the Debian > > packages. Does the normal kernel build usually install these? I wonder > > why it didn't for 2.2.10? > > In Debian, the headers in /usr/include/linux and /usr/include/asm are > not symlinks to the kernel source, but are supplied by libc6-dev. As > this is periodically upgraded, they may be based on newer kernels--the > current potato version comes from 2.2.9. > > What I did to compile the vmware modules is to mv /usr/lib/linux to some > other location and replace it with a symlink to the headers in my 2.2.10 > kernel source. You can probably use symlinks all the time, but you > should read /usr/doc/libc6-dev/FAQ.Debian.gz to understand the rationale > as to why the headers are packaged this way. > > Bob > > -- > Bob Nielsen Internet: [EMAIL PROTECTED] > Tucson, AZ AMPRnet: [EMAIL PROTECTED] > DM42nh http://www.primenet.com/~nielsen > > > -- > Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] < /dev/null >
Re: /usr/include/linux and /usr/include/asm?
Look in the archives here: http://www.debian.org/Lists-Archives/debian-user-9702/msg00686.html for a note from linus about why things are the way they are. Carl
Re: /usr/include/linux and /usr/include/asm?
%% Bob Nielsen <[EMAIL PROTECTED]> writes: bn> In Debian, the headers in /usr/include/linux and /usr/include/asm are bn> not symlinks to the kernel source, but are supplied by libc6-dev. As bn> this is periodically upgraded, they may be based on newer kernels--the bn> current potato version comes from 2.2.9. Uhmm... bn> What I did to compile the vmware modules is to mv /usr/lib/linux to some bn> other location and replace it with a symlink to the headers in my 2.2.10 bn> kernel source. That's what I did, too. Didn't stop me, I was just curious. bn> You can probably use symlinks all the time, but you should read bn> /usr/doc/libc6-dev/FAQ.Debian.gz to understand the rationale as to bn> why the headers are packaged this way. 'Kay, I will when I get home. PS. I must say, without have read the rationale, that this seems _very_ drain bamaged to me (shipping the kernel headers with the libc package, I mean). Maybe I will be enlighted by the FAQ :) -- --- Paul D. Smith <[EMAIL PROTECTED]> Network Management Development "Please remain calm...I may be mad, but I am a professional." --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them.
Re: /usr/include/linux and /usr/include/asm?
On Mon, Jun 28, 1999 at 11:24:55AM -0400, Paul D. Smith wrote: > I tried to install vmware over the weekend and it wanted to compile a > kernel module for my 2.2.10 kernel. It complained because my linux > kernel header version was still 2.2.9. I looked and sure enough, > /usr/include/linux and /usr/include/asm were both real directories with > real files. > > Aren't these typically supposed to be symlinks to /usr/src/linux/...? > > Also, how did the headers there get up to 2.2.9? I haven't done > anything fancy to copy headers into those directories, and I've been > downloading kernel patches from www.linuxhq.com etc, not the Debian > packages. Does the normal kernel build usually install these? I wonder > why it didn't for 2.2.10? In Debian, the headers in /usr/include/linux and /usr/include/asm are not symlinks to the kernel source, but are supplied by libc6-dev. As this is periodically upgraded, they may be based on newer kernels--the current potato version comes from 2.2.9. What I did to compile the vmware modules is to mv /usr/lib/linux to some other location and replace it with a symlink to the headers in my 2.2.10 kernel source. You can probably use symlinks all the time, but you should read /usr/doc/libc6-dev/FAQ.Debian.gz to understand the rationale as to why the headers are packaged this way. Bob -- Bob Nielsen Internet: [EMAIL PROTECTED] Tucson, AZ AMPRnet: [EMAIL PROTECTED] DM42nh http://www.primenet.com/~nielsen
Re: /usr/include/linux and /usr/include/asm?
> > Also, how did the headers there get up to 2.2.9? I haven't done > > anything fancy to copy headers into those directories, and I've been > > downloading kernel patches from www.linuxhq.com etc, not the Debian > > packages. Does the normal kernel build usually install these? I wonder > > why it didn't for 2.2.10? > > This seems strange. How did you upgrade your kernel to 2.2.9? I believe the headers are in the libc6-dev package in potato... they're certianly in one of the libc6-* packages. you can always: dpkg -S /usr/include/linux/ to find out for sure. --Evan
Re: /usr/include/linux and /usr/include/asm?
[EMAIL PROTECTED] (Paul D. Smith) writes: > I tried to install vmware over the weekend and it wanted to compile a > kernel module for my 2.2.10 kernel. It complained because my linux > kernel header version was still 2.2.9. I looked and sure enough, > /usr/include/linux and /usr/include/asm were both real directories with > real files. > > Aren't these typically supposed to be symlinks to /usr/src/linux/...? With Debian it's different. There is an oppinion that the symlinks may not work in some cases, ans so Debian installs the headers in real directories. If you use Debian's way of building and installing a new kernel, then probably it would do this for you. I come from Slackware and I am used to upgrading the kernel old-fashioned way. I installed the symlinks ever since I installed Debian, and have had no problems with this all through kernels 2.0.36 - 2.2.10. > Also, how did the headers there get up to 2.2.9? I haven't done > anything fancy to copy headers into those directories, and I've been > downloading kernel patches from www.linuxhq.com etc, not the Debian > packages. Does the normal kernel build usually install these? I wonder > why it didn't for 2.2.10? This seems strange. How did you upgrade your kernel to 2.2.9? -- Arcady Genkin "... without money one gets nothing in this world, not even a certificate of eternal blessedness in the other world..." (S. Kierkegaard)
/usr/include/linux and /usr/include/asm?
I tried to install vmware over the weekend and it wanted to compile a kernel module for my 2.2.10 kernel. It complained because my linux kernel header version was still 2.2.9. I looked and sure enough, /usr/include/linux and /usr/include/asm were both real directories with real files. Aren't these typically supposed to be symlinks to /usr/src/linux/...? Also, how did the headers there get up to 2.2.9? I haven't done anything fancy to copy headers into those directories, and I've been downloading kernel patches from www.linuxhq.com etc, not the Debian packages. Does the normal kernel build usually install these? I wonder why it didn't for 2.2.10? -- --- Paul D. Smith <[EMAIL PROTECTED]> Network Management Development "Please remain calm...I may be mad, but I am a professional." --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them.
Re: /usr/include/linux, /usr/include/asm, ...
Hi, The canned response comes from the readme file included with the kernel headers package. It has been gleaned from various discussions on the Debian Lists, and from private email from David Engel and Linus Torvalds. I am given to understand that Linus will incorporate language to recommend not using the symlinks when glibc 2.0 comes in wider use (since that library also provides it's own /usr/include/linux etc). The GNU libc v2.0 is where Linux is headed for (libc6). That library follows the conventions used in Debian today, so we all have to get used to this. Also, look at /usr/doc/libc5/FAQ.gz (It is a subset of my canned response, but is a more widely circulated document) manoj -- Diplomacy is the art of saying "nice doggy" until you can find a rock. Manoj Srivastava mailto:[EMAIL PROTECTED]> Mobile, Alabama USAhttp://www.datasync.com/%7Esrivasta/> -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: /usr/include/linux, /usr/include/asm, ...
Manoj Srivastava typed: > Hi, > > I'll reverse the question: why are you using the links? > The links are ignored anyway while compiling the kernel, so that's > not it. However, you may totally confuse some other program (during > compilation) that does not expect changes that are made in the kernel > includes. You see, changes may be made in kernel headers in concert > with other include files, which have not been upgraded, files that > are not required for kernel builds, but may be required for package > XYZ. The links being ignored is interesting. I guess you mean the links are not neccessary due to an -I/usr/src/linux/include type parameter being used with gcc. The reason why *I* need the symlinks in is for my specific circumstances. For those that don't understand what the bunch of letters after my name (or even the ones after Bruce's) I'm a radio amateur. There is a flurry of activity going on here, as we build a lot of things, new protocols included, for use in amateur radio. This usually means the tools need to be upgraded every 8 patch levels or so. Naturally, I'm talking about 2.1.x kernels. > So, what else are the links good for? Most programs do not > (and should not) depend on kernel version specific api's; and the > handful that do should ask for and include -I/usr/src/linux anyway. What is the "Linux position" on asking to use /usr/src/linux includes? If this is the way things are going, can you point me to a reference of this? For example, where is the canned reply from? I'll let the people on linux-hams know this may be something we need to look at, it will at least draw some discussion there. - Craig -- // /\ | | | Craig Small VK2XLZ @home: [EMAIL PROTECTED] ||==||===|==|=| [44.136.13.17] @play: [EMAIL PROTECTED] \\ \/ | | | finger [EMAIL PROTECTED] for PGP key! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: /usr/include/linux, /usr/include/asm, ...
> Hamish> Besides, the gcc manual page says: -I "Append directory > =09Are you sure? Also the manual page warn to look at the info > pages, as so: True. Unfortunate (imho) that GNU cannot stick with the standard documentation system, or extend it, rather than replacing it with something that requires a tutorial just for simple first use (info). > `-IDIR' > Add the directory DIRECTORY to the head of the list of directories Ahh well, different to the manual page entirely. I'll keep trying ftape. Thanks. Hamish -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: /usr/include/linux, /usr/include/asm, ...
Hi, >>"Hamish" == Hamish Moffatt <[EMAIL PROTECTED]> writes: Hamish> Has anyone had any luck compiling (z)ftape 3.02 on debian, Hamish> then? I've tried, but it (reasonably) requires current kernel Hamish> headers, and despite adding the above to several Makefiles, it Hamish> still does not look in /usr/src/linux first. Hamish> Besides, the gcc manual page says: -I "Append directory Hamish> to the list of directories searched for include files.", which Hamish> implies that -I/usr/src/linux will be added to the very end of Hamish> the search path, after /usr/include; ie this will really do Hamish> nothing except for new (as opposed to updated) kernel header Hamish> files. It certainly does not work for me. Are you sure? Also the manual page warn to look at the info pages, as so: WARNING The information in this man page is an extract from the full documentation of the GNU C compiler, and is limited to the meaning of the options. This man page is not kept up to date except when volun teers want to maintain it. If you find a discrepancy between the man page and the software, please check the Info file, which is the authoritative documentation. So, checking the authoritative documentation, we have the following: File: gcc.info, Node: Directory Options, Next: Target Options, Prev: Link Op\ tions, Up: Invoking GCC Options for Directory Search These options specify directories to search for header files, for libraries and for parts of the compiler: `-IDIR' Add the directory DIRECTORY to the head of the list of directories to be searched for header files. This can be used to override a system header file, substituting your own version, since these directories are searched before the system header file directories. If you use more than one `-I' option, the directories are scanned in left-to-right order; the standard system directories come after. `-I-' Any directories you specify with `-I' options before the `-I-' option are searched only for the case of `#include "FILE"'; they are not searched for `#include '. If additional directories are specified with `-I' options after the `-I-', these directories are searched for all `#include' directives. (Ordinarily *all* `-I' directories are used this way.) In addition, the `-I-' option inhibits the use of the current directory (where the current input file came from) as the first search directory for `#include "FILE"'. There is no way to override this effect of `-I-'. With `-I.' you can specify searching the directory which was current when the compiler was invoked. That is not exactly the same as what the preprocessor does by default, but it is often satisfactory. `-I-' does not inhibit the use of the standard system directories for header files. Thus, `-I-' and `-nostdinc' are independent. Also: `-include FILE' Process FILE as input before processing the regular input file. In effect, the contents of FILE are compiled first. Any `-D' and `-U' options on the command line are always processed before `-include FILE', regardless of the order in which they are written. All the `-include' and `-imacros' options are processed in the order in which they are written. `-idirafter DIR' Add the directory DIR to the second include path. The directories on the second include path are searched when a header file is not found in any of the directories in the main include path (the one that `-I' adds to). `-iprefix PREFIX' Specify PREFIX as the prefix for subsequent `-iwithprefix' options. `-iwithprefix DIR' Add a directory to the second include path. The directory's name is made by concatenating PREFIX and DIR, where PREFIX was specified previously with `-iprefix'. If you have not specified a prefix yet, the directory containing the installed passes of the compiler is used as the default. `-iwithprefixbefore DIR' Add a directory to the main include path. The directory's name is made by concatenating PREFIX and DIR, as in the case of `-iwithprefix'. `-isystem DIR' Add a directory to the beginning of the second include path, marking it as a system directory, so that it gets the same special treatment as is applied to the standard system directories. `-nostdinc' Do not search the standard system directories for header files. Only the directories you have specified with `-I' options (and the current directory, if appropriate) are searched. *Note Directory Options::, for information on `-I
Re: /usr/include/linux, /usr/include/asm, ...
On Tue, 18 Feb 1997, Hamish Moffatt wrote: > > So, what else are the links good for? Most programs do not > > (and should not) depend on kernel version specific api's; and the > > handful that do should ask for and include -I/usr/src/linux anyway. > > Has anyone had any luck compiling (z)ftape 3.02 on debian, then? > I've tried, but it (reasonably) requires current kernel headers, > and despite adding the above to several Makefiles, it still > does not look in /usr/src/linux first. > > Besides, the gcc manual page says: -I "Append directory > to the list of directories searched for include files.", > which implies that -I/usr/src/linux will be added to the > very end of the search path, after /usr/include; ie this will > really do nothing except for new (as opposed to updated) > kernel header files. It certainly does not work for me. > > Actually, the correct choice is -I/usr/src/linux/include/ And Include paths that are put on the command line get used before any standard paths. I use this to my benefit many times. You have to do this to compile recent modutils, any kernel modules, etc... Works great if you get the right directory. Good Luck, Erv ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ ==-- _ / / \ ---==---(_)__ __ __/ / /\ \- [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / / /_/\ \ \ - [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ /__\ \ \ - [EMAIL PROTECTED] http://www.linux.org \_\/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: /usr/include/linux, /usr/include/asm, ...
On Feb 18, Hamish Moffatt wrote > > So, what else are the links good for? Most programs do not > > (and should not) depend on kernel version specific api's; and the > > handful that do should ask for and include -I/usr/src/linux anyway. > > Has anyone had any luck compiling (z)ftape 3.02 on debian, then? > I've tried, but it (reasonably) requires current kernel headers, > and despite adding the above to several Makefiles, it still > does not look in /usr/src/linux first. > > Besides, the gcc manual page says: Like most GNU manpages, it says: refer to the info version for up to date / more complete information. There you find -isystem dir Add a directory to the beginning of the second include path, marking it as a system directory, so that it gets the same special treatment as is applied to the standard system directories. -nostdinc Do not search the standard system directories for header files. Only the directories you have specified with `-I' options (and the current directory, if appropriate) are searched. See section Options for Directory Search, for information on `-I'. By using both `-nostdinc' and `-I-', you can limit the include-file search path to only those directories you specify explicitly. Which should provide you with the control needed. HTH, Ray -- PATRIOTISM A great British writer once said that if he had to choose between betraying his country and betraying a friend he hoped he would have the decency to betray his country. - The Hipcrime Vocab by Chad C. Mulligan -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: /usr/include/linux, /usr/include/asm, ...
> So, what else are the links good for? Most programs do not > (and should not) depend on kernel version specific api's; and the > handful that do should ask for and include -I/usr/src/linux anyway. Has anyone had any luck compiling (z)ftape 3.02 on debian, then? I've tried, but it (reasonably) requires current kernel headers, and despite adding the above to several Makefiles, it still does not look in /usr/src/linux first. Besides, the gcc manual page says: -I "Append directory to the list of directories searched for include files.", which implies that -I/usr/src/linux will be added to the very end of the search path, after /usr/include; ie this will really do nothing except for new (as opposed to updated) kernel header files. It certainly does not work for me. Hamish -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: /usr/include/linux, /usr/include/asm, ...
Hi, I'll reverse the question: why are you using the links? The links are ignored anyway while compiling the kernel, so that's not it. However, you may totally confuse some other program (during compilation) that does not expect changes that are made in the kernel includes. You see, changes may be made in kernel headers in concert with other include files, which have not been upgraded, files that are not required for kernel builds, but may be required for package XYZ. So, what else are the links good for? Most programs do not (and should not) depend on kernel version specific api's; and the handful that do should ask for and include -I/usr/src/linux anyway. Please also see the canned response below. manoj The headers were included in libc5-dev after a rash of very buggy alpha kernel releases (1.3.7* or something like that) that proceeded to break compilations, etc. Kernel versions are changed far more rapidly than libc is, and there are higer chances that people install a custom kernel than they install custom libc. The kernel headers used to make sense exporting to user space, but the user space thing has grown so much that it's really not practical any more. And technically, the symlinks really aren't very good. As of glibc, the kernel headers will really be _kernel_ headers, and user level includes are user level includes, because it is no longer possible to try to synchronize the libc and the kernel the way it used to be. The symlinks have been a bad idea for at least a year now, and the problem is just how to get rid of them gracefully. The _only_ reason for the symlinks is to immediately give access to new features in the kernel when those happen. New ioctl numbers etc etc. That was an overriding concern early on: the kernel interfaces expanded so rapidly even in "normal" areas that having the synchronization that symlinks offered was a good thing. However, the kernel interfaces aren't really supposed to change all that quickly any more, and more importantly: the technical users know how to fix things any way they want, so if they want a new ioctl number to show up they can actually edit the header files themselves, for example. But having separation is good for the non-technical user, because there are less surprises and package dependencies. Add to that the fact that few programs really need the more volatile elements of the header files (that is, things that really change from kernel version to kernel version), [before you reject this, consider: programs compiled on one kernel version usually work on other kernels]. So, it makes sense that a set of headers be provided from a known good kernel version, and that is sufficient for compiling most programs, (it also makes the compile time environments for programs on debian machines a well known one, easing the process of dealing with problem reports), the few programs that really depend on cutting edge kernel data structures may just use -I/usr/src/linux/include (provided that kernel-headers or kernel-source exists on the system). Most programs, even if they include , do not really depend on the version of the kernel, as long as the kernel versions are not too far off, they will work. And the headers provided in libc5-dev are just that. libc5-deb is uploaded frequently enough that it never lags too far behind the latest released kernel. There are two different capabilities which are the issue, and the kernel-packages and libc5-dev address different ones: a) The kernel packages try to provide a stable, well behaved kernel and modules, and may be upgraded whenever there are significant advances in those directions (bug fixes, more/better module support, etc). These, however, may not have include files that are non-broken as far as non-kernel programs are concerned, and the quality of the development/compilation environment is not the kernel packages priority (Also, please note that the kernel packages are tied together, so kernel-source, headers, and image are produced in sync) b) Quality of the development/compilation environment is the priority of libc5-dev package, and it tries to ensure that the headers it provides would be stable and not break non-kernel programs. This assertion may fail for alpha kernels, which may otherwise be perfectly stable, hence the need for a different set of known-good kernel include files. -- Marriage is a three ring circus: The engagement ring, the wedding ring, and the suffering. Manoj Srivastava mailto:[EMAIL PROTECTED]> Mobile, Alabama USAhttp://www.datasync.com/%7Esrivasta/> -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
/usr/include/asm
some software looks for /usr/include/asm, which doesn't exist, but probably should as a symlink to asm-i386. Just a minor bug report that's probably well known. --Z -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
