I had some problems while compiling some applications
with the 2.4.0 kernel.
The problem was a conflict between string.h from the libc
and the one from the kernel, which is included in fs.h
So, using <string.h> and <linux/fs.h> at the same time
brings some conflicts.
It seems to me that <linux/string.h> should not be apparent
from user mode, so I did this patch:
--- fs.h-orig Fri Feb 2 23:55:35
2001
+++ fs.h Fri Feb 2 21:26:05
2001
@@ -20,7 +20,7
@@
#include
<linux/stat.h>
#include
<linux/cache.h>
#include
<linux/stddef.h>
-#include
<linux/string.h>
+/* #include <linux/string.h>
*/
#include
<asm/atomic.h>
#include
<asm/bitops.h>
@@ -190,6 +190,7
@@
#include
<asm/semaphore.h>
#include
<asm/byteorder.h>
+#include
<linux/string.h>
extern void update_atime (struct inode
*);
#define UPDATE_ATIME(inode) update_atime
(inode)
Like this, the #include <linux/string.h> is "protected"
by a #ifdef __KERNEL__, so I don't have any conflict any more.
I recompiled my kernel without any problem since I did that patch.
Regards.
Jocelyn Mayer.
On Sat, 03 Feb 2001 00:04:16 +0100,
Jocelyn Mayer <[email protected]> wrote:
>I had some problems while compiling some applications
>with the 2.4.0 kernel.
>The problem was a conflict between string.h from the libc
>and the one from the kernel, which is included in fs.h
Rule 1. Applications must not include include kernel headers directly.
Rule 2. Any glibc that has a symlink from /usr/include/{linux,asm} to
/usr/src/linux/include/{linux,asm} is wrong.
Relying on /usr/include/{linux,asm} always pointing at the current
kernel source is broken as designed. /usr/include/{linux,asm} must be
real directories that are shipped as part of glibc, not symlinks to
some random version of the kernel. Fix /usr/include.
Keith Owens wrote:
> Rule 2. Any glibc that has a symlink from
> /usr/include/{linux,asm} to /usr/src/linux/include/{linux,asm}
> is wrong.
Such symlinks are created by the user.
> Relying on /usr/include/{linux,asm} always pointing at the
> current kernel source is broken as designed.
>From glibc 2.2.1 FAQ:
2.17. I have /usr/include/net and /usr/include/scsi as symlinks
into my Linux source tree. Is that wrong?
{PB} This was necessary for libc5, but is not correct when
using glibc. Including the kernel header files directly in user
programs usually does not work (see question 3.5). glibc
provides its own <net/*> and <scsi/*> header files to replace
them, and you may have to remove any symlink that you have in
place before you install glibc. However, /usr/include/asm and
/usr/include/linux should remain as they were.
Keith, are you saying that glibc is wrong?
3.5. On Linux I've got problems with the declarations in Linux
kernel headers.
{UD,AJ} On Linux, the use of kernel headers is reduced to the
minimum. This gives Linus the ability to change the headers
more freely. Also, user programs are now insulated from changes
in the size of kernel data structures.
For example, the sigset_t type is 32 or 64 bits wide in the
kernel. In glibc it is 1024 bits wide. This guarantees that
when the kernel gets a bigger sigset_t (for POSIX.1e realtime
support, say) user programs will not have to be recompiled.
Consult the header files for more information about the
changes.
Therefore you shouldn't include Linux kernel header files
directly if glibc has defined a replacement. Otherwise you
might get undefined results because of type conflicts.
> /usr/include/{linux,asm} must be real directories that are
> shipped as part of glibc, not symlinks to some random version
> of the kernel. Fix /usr/include.
But make install didn't create them. I built 2.2 and 2.2.1.
--
Fr?d?ric L. W. Meunier - http://www.pervalidus.net/
0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niter?i-RJ BR)
>>>>> "Fr?d?ric" == Fr?d?ric L W Meunier <[email protected]> writes:
Fr?d?ric> Keith Owens wrote:
>> Rule 2. Any glibc that has a symlink from
>> /usr/include/{linux,asm} to /usr/src/linux/include/{linux,asm}
>> is wrong.
Fr?d?ric> Such symlinks are created by the user.
>> Relying on /usr/include/{linux,asm} always pointing at the
>> current kernel source is broken as designed.
Fr?d?ric> From glibc 2.2.1 FAQ:
Fr?d?ric> 2.17. I have /usr/include/net and /usr/include/scsi as
Fr?d?ric> symlinks into my Linux source tree. Is that wrong?
Fr?d?ric> {PB} This was necessary for libc5, but is not correct
Fr?d?ric> when using glibc. Including the kernel header files
Fr?d?ric> directly in user programs usually does not work (see
Fr?d?ric> question 3.5). glibc provides its own <net/*> and
Fr?d?ric> <scsi/*> header files to replace them, and you may have
Fr?d?ric> to remove any symlink that you have in place before you
Fr?d?ric> install glibc. However, /usr/include/asm and
Fr?d?ric> /usr/include/linux should remain as they were.
Fr?d?ric> Keith, are you saying that glibc is wrong?
You both seem to be saying the same thing: that symlinks for
/usr/include/{linux,asm} are wrong.
Why try to argue when you agree?
(Debian does this right; last I heard Red-Hat didn't)
--
Brian May <[email protected]>
On Sat, 3 Feb 2001 00:49:26 -0200,
Fr d ric L. W. Meunier <[email protected]> wrote:
>Keith Owens wrote:
>> Relying on /usr/include/{linux,asm} always pointing at the
>> current kernel source is broken as designed.
>
>From glibc 2.2.1 FAQ:
>
>2.17. I have /usr/include/net and /usr/include/scsi as symlinks
> into my Linux source tree. Is that wrong?
>
>{PB} This was necessary for libc5, but is not correct when
>using glibc. Including the kernel header files directly in user
>programs usually does not work (see question 3.5). glibc
>provides its own <net/*> and <scsi/*> header files to replace
>them, and you may have to remove any symlink that you have in
>place before you install glibc. However, /usr/include/asm and
>/usr/include/linux should remain as they were.
>
>Keith, are you saying that glibc is wrong?
Not me, Linus says that glibc is wrong.
"I've asked glibc maintainers to stop the symlink insanity for the
last few years now, but it doesn't seem to happen.
Basically, that symlink should not be a symlink. It's a symlink for
historical reasons, none of them very good any more (and haven't been
for a long time), and it's a disaster unless you want to be a C
library developer. Which not very many people want to be.
The fact is, that the header files should match the library you link
against, not the kernel you run on."
http://www.mail-archive.com/[email protected]/2000-month-07/msg04096.html
for the rest of Linus's reasons.
>>>>> "Keith" == Keith Owens <[email protected]> writes:
>> {PB} This was necessary for libc5, but is not correct when
>> using glibc. Including the kernel header files directly in user
>> programs usually does not work (see question 3.5). glibc
>> provides its own <net/*> and <scsi/*> header files to replace
>> them, and you may have to remove any symlink that you have in
>> place before you install glibc. However, /usr/include/asm and
>> /usr/include/linux should remain as they were.
>>
>> Keith, are you saying that glibc is wrong?
Keith> Not me, Linus says that glibc is wrong.
Keith> "I've asked glibc maintainers to stop the symlink
Keith> insanity for the last few years now, but it doesn't seem to
Keith> happen.
Keith> Basically, that symlink should not be a symlink. It's a
Keith> symlink for historical reasons, none of them very good any
Keith> more (and haven't been for a long time), and it's a
Keith> disaster unless you want to be a C library developer.
Keith> Which not very many people want to be.
Keith> The fact is, that the header files should match the
Keith> library you link against, not the kernel you run on."
I read Keith's response as: the symlink is wrong.
I read the glib FAQ as: the symlink is wrong.
I read Linus' response as: the symlink is wrong.
Who is contradicting who here?
(perhaps that last sentence in the glibc FAQ is confusing, however the
rest of it clearly says that glibc contains its own version of those
files, and a symlink should *not* be used. I think the part "[...] you
may have to remove any symlink [...]" is clear enough).
--
Brian May <[email protected]>
On 3 Feb 2001, Brian May wrote:
> >>>>> "Keith" == Keith Owens <[email protected]> writes:
>
> >> {PB} This was necessary for libc5, but is not correct when
> >> using glibc. Including the kernel header files directly in user
> >> programs usually does not work (see question 3.5). glibc
> >> provides its own <net/*> and <scsi/*> header files to replace
> >> them, and you may have to remove any symlink that you have in
> >> place before you install glibc. However, /usr/include/asm and
> >> /usr/include/linux should remain as they were.
> >>
> >> Keith, are you saying that glibc is wrong?
>
> Keith> Not me, Linus says that glibc is wrong.
>
> Keith> "I've asked glibc maintainers to stop the symlink
> Keith> insanity for the last few years now, but it doesn't seem to
> Keith> happen.
>
> Keith> Basically, that symlink should not be a symlink. It's a
> Keith> symlink for historical reasons, none of them very good any
> Keith> more (and haven't been for a long time), and it's a
> Keith> disaster unless you want to be a C library developer.
> Keith> Which not very many people want to be.
>
> Keith> The fact is, that the header files should match the
> Keith> library you link against, not the kernel you run on."
>
>
> I read Keith's response as: the symlink is wrong.
> I read the glib FAQ as: the symlink is wrong.
> I read Linus' response as: the symlink is wrong.
>
> Who is contradicting who here?
>
> (perhaps that last sentence in the glibc FAQ is confusing, however the
> rest of it clearly says that glibc contains its own version of those
> files, and a symlink should *not* be used. I think the part "[...] you
> may have to remove any symlink [...]" is clear enough).
No, it clearly says that glibc contains its own versions of the net/* and
scsi/* files, and that /usr/include/asm and /usr/include/linux should
remain as they were. Since they were symlinks in libc5 (which is what
'originally' seems to be referring to), they should still be symlinks.
Brian (who really doesn't care either way)
>>>>> "Brian" == Brian Wellington <[email protected]> writes:
Brian> No, it clearly says that glibc contains its own versions of
Brian> the net/* and scsi/* files, and that /usr/include/asm and
Brian> /usr/include/linux should remain as they were. Since they
Brian> were symlinks in libc5 (which is what 'originally' seems to
Brian> be referring to), they should still be symlinks.
Oh I see now.
Sorry for any confusion caused.
--
Brian May <[email protected]>
> kernel source is broken as designed. /usr/include/{linux,asm} must be
> real directories that are shipped as part of glibc, not symlinks to
> some random version of the kernel. Fix /usr/include.
You need to fix the kernel headers too - libc5 doesnt work otherwise
Keith Owens <[email protected]> writes:
> Basically, that symlink should not be a symlink. It's a symlink for
> historical reasons, none of them very good any more (and haven't been
> for a long time), and it's a disaster unless you want to be a C
> library developer. Which not very many people want to be.
>
> The fact is, that the header files should match the library you link
> against, not the kernel you run on."
So what is your advice? Would the "correct" action be to take a
snapshot of the appropriate kernel directories against which glibc is
built? (ie to copy the directories (or those files needed) to
/usr/include/asm and /usr/include/linux)
On the other hand, if you are building "system level" tools (eg which
communicate with device drivers directly using IOCTLs) you may need to
use the kernel header files, in which case I suppose you should
include them from the kernel source tree not /usr/include.
In both case, I think the problem is not so much in code which you
write yourself (where you control include paths etc) but in building
3rd party applications which may not have used the "correct" include
paths and therefore will not build "out of the box".
On 03 Feb 2001 08:48:54 +0000,
Graham Murray <[email protected]> wrote:
>So what is your advice? Would the "correct" action be to take a
>snapshot of the appropriate kernel directories against which glibc is
>built? (ie to copy the directories (or those files needed) to
>/usr/include/asm and /usr/include/linux)
This has all been thrashed out before. Read the threads
http://www.mail-archive.com/[email protected]/2000-month-07/msg04096.html
http://www.mail-archive.com/[email protected]/msg18256.html
Keith Owens <[email protected]> writes:
> This has all been thrashed out before. Read the threads
>
> http://www.mail-archive.com/[email protected]/2000-month-07/msg04096.html
> http://www.mail-archive.com/[email protected]/msg18256.html
I don't think that these address my question. I was asking about when
building (upgrading) glibc from source. I believe that the glibc
headers are "derived" from the kernel against which it is built. So,
irrespective of what the glibc maintainers do, would it be advisable
for the user to remove the symlinks and copy the directories from the
kernel tree and into /usr/include?
On 03 Feb 2001 10:09:39 +0000,
Graham Murray <[email protected]> wrote:
>Keith Owens <[email protected]> writes:
>> This has all been thrashed out before. Read the threads
>>
>> http://www.mail-archive.com/[email protected]/2000-month-07/msg04096.html
>> http://www.mail-archive.com/[email protected]/msg18256.html
>
>I don't think that these address my question. I was asking about when
>building (upgrading) glibc from source. I believe that the glibc
>headers are "derived" from the kernel against which it is built.
That way everybody builds a different glibc. Does that strike you as a
good idea? glibc should be shipped with standard include files.