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.co
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
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 /us
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 man
> 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 li
> "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
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). gl
> "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 fi
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
> "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.
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 gl
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 mu
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 u
13 matches
Mail list logo
