Re: Fix for include/linux/fs.h in 2.4.0 kernels
On 03 Feb 2001 10:09:39 +, 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/linux-kernel@vger.rutgers.edu/2000-month-07/msg04096.html >> http://www.mail-archive.com/linux-kernel@vger.kernel.org/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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
Keith Owens <[EMAIL PROTECTED]> writes: > This has all been thrashed out before. Read the threads > > http://www.mail-archive.com/linux-kernel@vger.rutgers.edu/2000-month-07/msg04096.html > http://www.mail-archive.com/linux-kernel@vger.kernel.org/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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
On 03 Feb 2001 08:48:54 +, 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/linux-kernel@vger.rutgers.edu/2000-month-07/msg04096.html http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg18256.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
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". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
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". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
On 03 Feb 2001 08:48:54 +, 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/linux-kernel@vger.rutgers.edu/2000-month-07/msg04096.html http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg18256.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
Keith Owens [EMAIL PROTECTED] writes: This has all been thrashed out before. Read the threads http://www.mail-archive.com/linux-kernel@vger.rutgers.edu/2000-month-07/msg04096.html http://www.mail-archive.com/linux-kernel@vger.kernel.org/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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
On 03 Feb 2001 10:09:39 +, 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/linux-kernel@vger.rutgers.edu/2000-month-07/msg04096.html http://www.mail-archive.com/linux-kernel@vger.kernel.org/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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
> "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]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
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 and 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)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
> "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 and 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]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
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 and 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/linux-kernel@vger.rutgers.edu/2000-month-07/msg04096.html
for the rest of Linus's reasons.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
> "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 and
Frédéric> 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]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
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 and 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)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Fix for include/linux/fs.h in 2.4.0 kernels
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 and at the same time brings some conflicts. It seems to me that should not be apparent from user mode, so I did this patch: --- fs.h-orig Fri Feb 2 23:55:35 2001 +++ fs.hFri Feb 2 21:26:05 2001 @@ -20,7 +20,7 @@ #include #include #include -#include +/* #include */ #include #include @@ -190,6 +190,7 @@ #include #include +#include extern void update_atime (struct inode *); #define UPDATE_ATIME(inode) update_atime (inode) Like this, the #include 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Fix for include/linux/fs.h in 2.4.0 kernels
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.hFri 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
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.
--
Frdric L. W. Meunier - http://www.pervalidus.net/
0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niteri-RJ BR)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
"Frdric" == Frdric L W Meunier [EMAIL PROTECTED] writes:
Frdric 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.
Frdric Such symlinks are created by the user.
Relying on /usr/include/{linux,asm} always pointing at the
current kernel source is broken as designed.
Frdric From glibc 2.2.1 FAQ:
Frdric 2.17. I have /usr/include/net and /usr/include/scsi as
Frdric symlinks into my Linux source tree. Is that wrong?
Frdric {PB} This was necessary for libc5, but is not correct
Frdric when using glibc. Including the kernel header files
Frdric directly in user programs usually does not work (see
Frdric question 3.5). glibc provides its own net/* and
Frdric scsi/* header files to replace them, and you may have
Frdric to remove any symlink that you have in place before you
Frdric install glibc. However, /usr/include/asm and
Frdric /usr/include/linux should remain as they were.
Frdric 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]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
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/linux-kernel@vger.rutgers.edu/2000-month-07/msg04096.html
for the rest of Linus's reasons.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
"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]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
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)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
"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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
