It would help if one could actually get hold of the changes.
Neither at home nor on my gmail account did I get them all. The gmane
also only has 5 of the 9 mails or so. Your archive only has sources
from a couple of versions back.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St
It would help if one could actually get hold of the changes.
Neither at home nor on my gmail account did I get them all. The gmane
also only has 5 of the 9 mails or so. Your archive only has sources
from a couple of versions back.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St
Evgeniy Polyakov wrote:
I've uploaded the latest changes to the homepage.
Thanks. But could you now update the patch so that it can be compiled
with the current upstream kernel? At least linux/kevent.h has
problems because of file-st accesses.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444
On 12/13/06, Teunis Peters <[EMAIL PROTECTED]> wrote:
Now that syscall macros have been pulled from the -mm tree, what method
is recommended to use syscalls?
glibc forever had a syscall() function for just that purpose. It was
never a good idea to use the macros since they didn't work in PIC.
On 12/13/06, Teunis Peters [EMAIL PROTECTED] wrote:
Now that syscall macros have been pulled from the -mm tree, what method
is recommended to use syscalls?
glibc forever had a syscall() function for just that purpose. It was
never a good idea to use the macros since they didn't work in PIC.
-
On 12/7/06, Andreas Schwab <[EMAIL PROTECTED]> wrote:
The quoted sentence is not shaded as an XSI extension, thus it is part of
POSIX-1:2001.
Perhaps I didn't make myself clear. The change I pointed at was
accepted to the interpretations track which means that if we would
create a Technical
On 12/7/06, Andreas Schwab [EMAIL PROTECTED] wrote:
The quoted sentence is not shaded as an XSI extension, thus it is part of
POSIX-1:2001.
Perhaps I didn't make myself clear. The change I pointed at was
accepted to the interpretations track which means that if we would
create a Technical
On 12/6/06, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
I'm quite aware of that, but I still think Sun has more resources to get
their particular viewpoint through the committee -- it's just a matter
of resources at hand. I myself had to largely drop out due to other
pressures, for example.
But
On 12/6/06, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
That's largely already the case, mostly because there is unfortunately
still a fair bit of rubber-stamping Solaris going on.
Don't say that, Peter.
I'm working on the committee now for many years and got most changes I
(and those telling
On 12/6/06, H. Peter Anvin [EMAIL PROTECTED] wrote:
That's largely already the case, mostly because there is unfortunately
still a fair bit of rubber-stamping Solaris going on.
Don't say that, Peter.
I'm working on the committee now for many years and got most changes I
(and those telling me
On 12/6/06, H. Peter Anvin [EMAIL PROTECTED] wrote:
I'm quite aware of that, but I still think Sun has more resources to get
their particular viewpoint through the committee -- it's just a matter
of resources at hand. I myself had to largely drop out due to other
pressures, for example.
But
Evgeniy Polyakov wrote:
It _IS_ how previous interface worked.
EXACTLY!
No, the old interface committed everything not only up to a given index.
This is the huge difference which makes or breaks it.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA
have probably noticed,
there was such an interface already, and I changed it. So, this will be the
last change of the interface. You think it should not be exported -
fine, it will not be.
Thanks.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from
much more complicated than adding a simple index comparison before
going to sleep.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More maj
licate functionality. If there are
performance problems with the POSIX timer implementation (and I have yet
to see indications) it should be fixed instead of worked around.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line "
be passed to userland in one or two int fields, I don't really
care. When reporting the event to the user code we cannot just point
into the ring buffer anyway. So while copying the data we can rewrite
it if necessary. I see no need to complicate the code more than it
already is.
--
➧ Ulrich
'd need to use indirect notification via
>> signal or pipe or something like that.
This is still something which is wanted.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
is sufficient and it should be passed up
to the user in the ptr member of struct ukevent.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majo
is sufficient and it should be passed up
to the user in the ptr member of struct ukevent.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
or pipe or something like that.
This is still something which is wanted.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
be passed to userland in one or two int fields, I don't really
care. When reporting the event to the user code we cannot just point
into the ring buffer anyway. So while copying the data we can rewrite
it if necessary. I see no need to complicate the code more than it
already is.
--
➧ Ulrich
. If there are
performance problems with the POSIX timer implementation (and I have yet
to see indications) it should be fixed instead of worked around.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
complicated than adding a simple index comparison before
going to sleep.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
have probably noticed,
there was such an interface already, and I changed it. So, this will be the
last change of the interface. You think it should not be exported -
fine, it will not be.
Thanks.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from
Evgeniy Polyakov wrote:
It _IS_ how previous interface worked.
EXACTLY!
No, the old interface committed everything not only up to a given index.
This is the huge difference which makes or breaks it.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA
lly when coupled with asynchronous filling of
ring buffer (i.e., without a syscal).
Let's solve problem in order of theirs appearance - what do you think
about above interface for ring buffer?
Looks better, yes.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To
with asynchronous filling of
ring buffer (i.e., without a syscal).
Let's solve problem in order of theirs appearance - what do you think
about above interface for ring buffer?
Looks better, yes.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from
.
while (1) {
if (!got_signal)
pselect()
if (got_signal) {
handle signal
got_signal = 0;
}
}
...
}
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
) {
if (!got_signal)
pselect()
if (got_signal) {
handle signal
got_signal = 0;
}
}
...
}
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
) since this makes it clear what should happen but
I can live with using the too-large mapping.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
it is implemented today.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
, anonymous mappings which have no access
permissions (i.e., PROT_NONE with MAP_PRIVATE and MAP_ANON). One
explicitly has to allocate such blocks, they don't appear naturally.
And the program in any case knows about the address space layout.
So, how about adding MREMAP_MAPOVERNONE or so?
--
➧ Ulrich
, anonymous mappings which have no access
permissions (i.e., PROT_NONE with MAP_PRIVATE and MAP_ANON). One
explicitly has to allocate such blocks, they don't appear naturally.
And the program in any case knows about the address space layout.
So, how about adding MREMAP_MAPOVERNONE or so?
--
➧ Ulrich
.
Just accept here that moving is not an option. If remap cannot be used
then a complete new mmap() with adjusted length is needed. That is
unnecessarily expensive. It is the reason why there is mremap(). But
mremap() with MREMAP_MAYMOVE is unreliable as it is implemented today.
--
➧ Ulrich
it clear what should happen but
I can live with using the too-large mapping.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
On 8/18/05, Alan Cox <[EMAIL PROTECTED]> wrote:
> Perhaps those application authors should provide a management interface
> to do so within the soft limit range at least. Its not clear to me that
> growing the fd array on a process is even safe. Some programs do size
> arrays at startup after
On 8/18/05, Alan Cox [EMAIL PROTECTED] wrote:
Perhaps those application authors should provide a management interface
to do so within the soft limit range at least. Its not clear to me that
growing the fd array on a process is even safe. Some programs do size
arrays at startup after querying
t from select. The
userlevel code will take care of the difference. The kernel code is
good as proposed.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
select. The
userlevel code will take care of the difference. The kernel code is
good as proposed.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
On 8/1/05, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> I'm not quite sure you are right Ulrich. Given this little bit from
> SUSv3 about SA_RESTART in the page describing sigaction (
> http://www.opengroup.org/onlinepubs/009695399/functions/sigaction.html
> ) :
It's not an official SA_RESTART since
On 7/31/05, Roland McGrath <[EMAIL PROTECTED]> wrote:
> However, there is in fact no bug here. The test program is just wrong.
> sigwait returns zero or an error number, as POSIX specifies.
No question, no error is detected incorrectly.
But sigwait is not a function specified with an EINTR
On 7/31/05, Roland McGrath [EMAIL PROTECTED] wrote:
However, there is in fact no bug here. The test program is just wrong.
sigwait returns zero or an error number, as POSIX specifies.
No question, no error is detected incorrectly.
But sigwait is not a function specified with an EINTR error
On 8/1/05, Jesper Juhl [EMAIL PROTECTED] wrote:
I'm not quite sure you are right Ulrich. Given this little bit from
SUSv3 about SA_RESTART in the page describing sigaction (
http://www.opengroup.org/onlinepubs/009695399/functions/sigaction.html
) :
It's not an official SA_RESTART since the
On 7/30/05, Sanjoy Mahajan <[EMAIL PROTECTED]> wrote:
> so the return value should not be 4 (or the docs are not right).
This return value simply indicated EINTR (sigwait does not set errno,
read the docs).
The kernel simply doesn't restart the function in case of a signal.
It should do this,
On 7/30/05, Sanjoy Mahajan [EMAIL PROTECTED] wrote:
so the return value should not be 4 (or the docs are not right).
This return value simply indicated EINTR (sigwait does not set errno,
read the docs).
The kernel simply doesn't restart the function in case of a signal.
It should do this,
On Tue, 15 Feb 2005 13:58:28 +0100, Yves Crespin
<[EMAIL PROTECTED]> wrote:
>ThreadUnblockSignal();
>signo = WaitSignal();
>ThreadBlockSignal();
You expect this to work? Just read the POSIX spec or even the man
pages. All signals sigwait() waits for must be blocked
On Tue, 15 Feb 2005 13:58:28 +0100, Yves Crespin
[EMAIL PROTECTED] wrote:
ThreadUnblockSignal();
signo = WaitSignal();
ThreadBlockSignal();
You expect this to work? Just read the POSIX spec or even the man
pages. All signals sigwait() waits for must be blocked before the
On Sun, 30 Jan 2005 23:56:07 -0800, Ben Greear <[EMAIL PROTECTED]> wrote:
>flags = fcntl(s, F_GETFL);
>flags |= (FD_CLOEXEC);
>if (fcntl(s, F_SETFL, flags) < 0) {
These have to be F_GETFD and F_SETFD respectively. Note L -> D.
-
To unsubscribe from this list: send the line
On Sun, 30 Jan 2005 23:56:07 -0800, Ben Greear [EMAIL PROTECTED] wrote:
flags = fcntl(s, F_GETFL);
flags |= (FD_CLOEXEC);
if (fcntl(s, F_SETFL, flags) 0) {
These have to be F_GETFD and F_SETFD respectively. Note L - D.
-
To unsubscribe from this list: send the line unsubscribe
timing and see
whether you can filter the difference out of the noise.
--
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â
signature.asc
Description: OpenPGP digital signature
timing and see
whether you can filter the difference out of the noise.
--
Ulrich Drepper Red Hat, Inc. 444 Castro St Mountain View, CA
signature.asc
Description: OpenPGP digital signature
On Fri, 21 Jan 2005 23:05:04 -0800, Chris Wright <[EMAIL PROTECTED]> wrote:
> Yeah, here it is. I refreshed it against a current kernel. It passes my
> same old test, where I select on /proc//status fd in exceptfds.
Looks certainly attractive to me. Nice small patch. How quickly
after the
On Fri, 21 Jan 2005 17:17:51 -0600, Brent Casavant <[EMAIL PROTECTED]> wrote:
> 2. select/poll on the fd return EWOULDBLOCK if the current value of
> the futex is not equal to the value of interest. Otherwise it
> behaves as FUTEX_FD currently does.
This is the problematic part.
On Fri, 21 Jan 2005 17:17:51 -0600, Brent Casavant [EMAIL PROTECTED] wrote:
2. select/poll on the fd return EWOULDBLOCK if the current value of
the futex is not equal to the value of interest. Otherwise it
behaves as FUTEX_FD currently does.
This is the problematic part. The
On Fri, 21 Jan 2005 23:05:04 -0800, Chris Wright [EMAIL PROTECTED] wrote:
Yeah, here it is. I refreshed it against a current kernel. It passes my
same old test, where I select on /proc/pid/status fd in exceptfds.
Looks certainly attractive to me. Nice small patch. How quickly
after the
cond:
It still means the documented API says there are no short reads.
So anyone doing a read() can expect a short read regardless of the fd
and is quite clear that reads can be interrupted by signals. "It is
not an error". Ever.
Of course are signal interruptions wrong if the signal uses SA_
the documented API says there are no short reads.
So anyone doing a read() can expect a short read regardless of the fd
and is quite clear that reads can be interrupted by signals. It is
not an error. Ever.
Of course are signal interruptions wrong if the signal uses SA_RESTART.
--
Ulrich Drepper Red Hat
features of
the processor first. The kernel can detect when the FPU is used for
the first time.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `
s was always the case
and necessary to implement the fast lazy FPU saving/restoring.
Processes which never use the FPU never initialize it.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat
e case
and necessary to implement the fast lazy FPU saving/restoring.
Processes which never use the FPU never initialize it.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' d
ssor first. The kernel can detect when the FPU is used for
the first time.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To u
ing else I couldn't care less since it's useless for
me.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from
Jens Axboe <[EMAIL PROTECTED]> writes:
> Does attached patch fix it?
Yes.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at r
++*i;
pthread_mutex_unlock (m1);
pthread_mutex_lock (m2);
}
return 0;
}
~~~~~~~
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `--
g this her/himself.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "u
t really care what the final implementation will be like. For
UP and SMP machines I definitely want to have as much as possible at
user-level. If you need a special libpthread for NUMA machines, so be
it.
--
---. ,-. 1325 Chesapeake Terr
the file change?
The kernel representation of the mutex must not be disassociated from
the shared memory region.
Even if you all think very little about Solaris, look at the kernel
interface for semaphores.
--
---. ,-. 1325 Chesa
unix file permissions on them ?
See above. Permissions are only allowed for named semaphores.
--
-------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `--
fd = open (name)
addr = mmap (..fd..)
close (fd)
sem_syscall (addr)
i.e., it can be mapped to a memory reference again.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat
r dealing with the common case without
syscalls can be applied here as well.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at r
with the common case without
syscalls can be applied here as well.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com
..)
close (fd)
sem_syscall (addr)
i.e., it can be mapped to a memory reference again.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com
n them ?
See above. Permissions are only allowed for named semaphores.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `-
The kernel representation of the mutex must not be disassociated from
the shared memory region.
Even if you all think very little about Solaris, look at the kernel
interface for semaphores.
--
---. ,-. 1325 Chesapeake Terrace
Ulri
the final implementation will be like. For
UP and SMP machines I definitely want to have as much as possible at
user-level. If you need a special libpthread for NUMA machines, so be
it.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper
.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
ad_mutex_unlock (m1);
pthread_mutex_lock (m2);
}
return 0;
}
~~~
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 940
Jens Axboe [EMAIL PROTECTED] writes:
Does attached patch fix it?
Yes.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com
since it's useless for
me.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line
s.
The rest seems OK. Thanks,
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the l
t seems OK. Thanks,
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscri
arently want.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
rogrammers to not
initialize.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
It is a programmer problem.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu
er problem.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
initialize.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [E
nd there is no guarantee that any of
the _SC_* constants are defined as macros. You'll have to add a
configure test.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 US
are defined as macros. You'll have to add a
configure test.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from
efully forever signal the
gcc semantics.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send th
forever signal the
gcc semantics.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line
stupid idea. No kernel and no libc modifications necessary. This is
the end of the story as far as I'm concerned.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `-
modifications necessary. This is
the end of the story as far as I'm concerned.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com
wrote the code.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECT
,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the F
you, as the other script suggested, execute libc.so.6?
Symlinks can be missing or can be wrong.
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `---
/i486-linux-libc5/lib/libc.so.5
and then look in that directory (/usr/i486-linux-libc5/lib).
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To un
.so files
there).
--
---. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAI
601 - 700 of 743 matches
Mail list logo
