| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
from i386 and x86_64.
|
|
not just on ENOENT (in particular, on EPERM). At least glibc does so.
Fixing this.
|
|
Make msync.c agree on this.
|
|
them enabled, so let's go all the way. There was a quick discussion on IRC about making the max baud rate configurable. That requires a bunch of #ifdef salting throughout all of the 'termios.h' files for the pre-processor to chew on. I'm going to pass on that for now.
|
|
|
|
else.
- internal_function is only used inside libc, so do not define it in
uClibc_arch_features.h on i386 if we are outside of libc.
|
|
Hi All,
this patch fixes a mismatch in ucontext struct between uClibc and kernel.
In this way a signal handler installed by sigaction can access
to the whole machine state correctly.
This can be applied both to trunk and nptl branch
|
|
are ELF-specific, not MMU-specific
|
|
Current MIPS readahead(), posix_fadvise(), posix_fadvise64() do not
match with kernel on all ABIs.
On O32 ABI, a padding is needed before a long long argument.
On N32/N64, a long long argument should be passed via a single register.
|
|
http://www.opengroup.org/onlinepubs/009695399/functions/posix_fadvise.html
states it returns error code instead of setting errno.
|
|
I actually suspect this code into the file uClibc/libc/sysdeps/linux/common/poll.c:
tval.tv_nsec = (timeout % 1000) *1000; <==== make only usec!
From milisecond this really needs a * 1000000 to make nanosecond. Without this
a 1100 milisecond timeout is converted into a 1 seconde and 100 microsecond
timeout! This can explain the weird result of the test code.
|
|
|
|
Daniel Jacobowitz on the mailing list. More information available at <http://www.uclibc.org/lists/uclibc/2007-May/017968.html> .
|
|
Linux kernel versions as reported by Joseph S. Myers on the mailing list. More information available at <http://www.uclibc.org/lists/uclibc/2007-May/017971.html> .
|
|
|
|
|
|
|
|
code does not create a new temp name as the code to do so is outside of the retry loop
|
|
|
|
Currently, tcgetpgrp() in uClibc uses an int to store a PID (fetched
via ioctl TIOCGPGRP). This causes problems on platforms where pid_t
is defined to be larger (e.g., uint64_t). Other functions in termios,
such as tcgetsid() and tcsetpgrp(), already pass a pid_t to ioctl(),
so the following patch does the same in tcgetpgrp() as well.
|
|
point but the files have "libc_hidden_proto(nanosleep)" which means it always
calls the libc.so version, never the wrapped version in libpthread.so that's a
cancellation point.
|
|
running LTP test suite on uClibc-nptl for sh4 I found a bug into pread
and pwrite functions. When the offset is negative it is not correctly
handled due to a missing shift operation, so it is passed to the
syscall as the highest unsigned positive value.
|
|
|
|
|
|
(without which busybox ping segfaults on error). Broken during locking
changes in in svn 16801.
|
|
|
|
|
|
|
|
* Add configurable buffer sizes for getpwnam() and getgrnam().
The default buffer size is, as before, 256 (glibc seems to use
1024 by default).
|
|
trigger a buffer overflow in that case
|
|
|
|
|
|
|
|
|
|
pointed out the solution. This fixes a segfault for me on exit from a
statically linked "hello world".)
|
|
|
|
On PowerPC, r13 is used for a small data pointer and needs to be set up
from _SDA_BASE_ (defined by the linker) at startup.
This is needed for the GCC testcase gcc.target/powerpc/980827-1.c to work.
This patch fixes that testcase (verified for both static and dynamic
linking).
|
|
|
|
emulate poll with ppoll.
|
|
|
|
with gcc 4.2. Renaming to make it a bit uncommon name.
|
|
|
|
The attached patch works around some compilation failures on
ia64 caused by the use of the C preprocessor ## operator, and
allows the ia64 default configuration to build again -- or, at
least get as far as an x86 build does (the current source tree
has some problems compiling because of conflicting type
declarations for __kernel_dev_t).
|
|
|
|
says "virtual memory exhausted" trying to build hello world.)
|
|
again, this makes the non-threaded case compile again. I have no idea
if this is the proper fix, I'm just tired if it not compiling for two
weeks.
|
|
(No idea if this is the right fix but it's something for now.)
|
|
Patch from Carmelo Amoroso <carmelo73@gmail.com>.
|
