Age | Commit message (Collapse) | Author |
|
Hello,
under some circumstances the following small example prints lots of
garbage onto the console and into the syslog:
#include <syslog.h>
int main ()
{
openlog("foo", LOG_CONS|LOG_NDELAY|LOG_PID|LOG_PERROR, LOG_DAEMON);
syslog (LOG_WARNING, "mlock: %m");
return 1;
}
The reason is, that sprintf returns with -1 and vsyslog dumps the
complete buffer onto stderr and the syslogd socket. The following
patch would fix the problem:
|
|
Remove use of cast-as-l-value extension, removed in GCC 3.5.
|
|
uClibc resolver doesn't lookup all search domains.
For example, if you have computer 'jenda.prague.my.cz' and resolv.conf:
search my.cz
nameserver xx.xx.xx.xx
try this:
ping jenda.prague.my.cz #works
ping jenda.prague #unknown host
libc/inet/resolv.c doesn't want to try search domains if the domain name
contains '.'. I don't find any reason for the behaviour in literature
and it is inconsistent with the glibc.
Patch is attached.
regards,
- jenda
|
|
Most of the time, no one ever notices, so there's not point eh ? Also
standardize tab usage.
|
|
Here is a small patch to add epoll support to uclibc.
The only thing I am not sure about is what needs to be done (if anything)
to make it work on 2.4/2.2 kernels (are the syscall numbers defined but
give errors when called or not?).
Tested on 2.6, though some other issues prevent more extensive testing at
the minute.
Mike Frysinger:
cleaned up patch and added checks to make sure that the syscall actually
exists, returning ENOSYS in cases where it doesn't.
|
|
|
|
|
|
|
|
Add pie support for mips
|
|
rename UCLIBC_PROPOLICE to UCLIBC_HAS_SSP
|
|
|
|
|
|
as the flags for all calls to 'as'
|
|
|
|
using uClibc. mincore() and the ones for Extended Attributes setxattr(), lsetxattr(), fsetxattr(), getxattr(), lgetxattr(), fgetxattr(), listxattr(), llistxattr(), flistxattr(), removexattr(), lremovexattr(), fremovexattr() which are optional.
|
|
> What's the correct way of calling llseek/_llseek?
> The manpage I have indicates _llseek and thats what the version of
> util-linux
> I tried use as well so compiling for uClibc fails.
> Would the following patch fix it or is it the apps that needs fixing?
|
|
The Arm crt0.S contains non-PIC code for locating _init and _fini sections.
This caused problems on my uclinux system when static constructors were
enabled.
The attached patch implements a PIC version of this code.
Paul
|
|
Here's an updated version of the patch I posted about a month ago. It
leaves -nostdinc alone, and uses -print-file-name=include instead of
-print-search-dirs to figure out where GCC's internal headers are.
Please let me know whether there are any portions of this patch you'd
like me to break into smaller pieces, to rework, or to give up trying
to get into uClibc :-) Thanks,
|
|
|
|
|
|
|
|
stack frame. This will make backtracing possible.
|
|
enabled. syslog() support should now work both inside and outside of chroots. erandom code left in but remains #ifdef out by default. May remove erandom completely in the future for uClibc unless the LFS guys and gals want to keep it.
|
|
enabled. syslog() support should now work both inside and outside of chroots. erandom code left in but remains #ifdef out by default. May remove erandom completely in the future for uClibc unless the LFS guys and gals want to keep it.
|
|
|
|
was incorrect in uClibc, and was 2 bytes too short. This caused uClibc
shared memory stuff to not behave correctly since struct ipc_perm was
included as the first member of, i.e. struct msqid_ds, so the content
of that struct were all shifted by two bytes. ugh. Apparently, few
people have used shared memory, msgctl(), etc with uClibc thus far,
-Erik
|
|
adding cruft to include/sys/time.h. But also, there's no sense in
making changes like this until we decide how we're going to approach
the hidden symbol transition.
|
|
for saving SRP separately.
|
|
binaries where the standard file descriptors are not opened.
-Erik
|
|
>>>>> On Tue, 19 Oct 2004 13:28:34 -0600, Erik Andersen <andersen@codepoet.org> said:
>> BTW, top of uClibc TODO list is "Fix syscall() on mips". What is a
>> problem?
andersen> It appears that uClibc's syscall() for mips works ok for
andersen> syscalls with a few arguments. But as I recall, it does not
andersen> work properly with _syscall5, _syscall6, _syscall7, etc.
andersen> Perhaps there is some mistake in its assumptions about the
andersen> mips/linux ABI regarding which syscall arguments are passed
andersen> via register vs which syscall arguments are passed on the
andersen> stack.
Hmm... I found a old fix in uClibc ML archive.
http://www.uclibc.org/lists/uclibc/2002-September/004459.html
But it seems somewhat broken. How about this fix instead? I tested
mmap with syscall() in mips. mips64 is not tested.
|
|
Hello!
Would the attached patch be acceptable (maybe instead of
__libc_gettimeofday using __gettimeofday)
We have some issues, see
http://bugs.gentoo.org/show_bug.cgi?id=65892
|
|
In a recent post to linux-mips ML (and libc-alpha ML), a problem with
inline syscalls was reported.
http://www.linux-mips.org/archives/linux-mips/2004-10/msg00142.html
It seems uClibc should be fixed also for newer gcc. Here is a patch.
|
|
The attached patch generalizes the use of PIE (all archs are brought in
sync that use/mention it: x86/ppc/frv) and makes use of it building the
target utils.
Tested on x86, ppc should be tested, frv uses -fPIE at one location, but
at another place -fpie, I don't know which is correct (could be both) and
misses the target addition in Config.in.
The test for ppc (requires the earlier sent crt-correction patch to work
correctly):
enable UCLIBC_PIE_SUPPORT, build uClibc and utils, check:
file ./utils/ldd, it should show shared object (instead of executable)
|
|
|
|
|
|
|
|
Hi. I found a mismatch between uClibc and kernel in semctl definition.
In uClibc/libc/misc/sysvipc/sem.c:
static inline _syscall4(int, __semctl, int, semid, int, semnum, int, cmd, union semun *, arg);
...
int semctl(int semid, int semnum, int cmd, ...)
...
arg = va_arg (ap, union semun);
...
return __semctl(semid, semnum, cmd, &arg);
But kernel's semctl is:
asmlinkage long sys_semctl (int semid, int semnum, int cmd, union semun arg)
The last argument is an union semun itself, not a pointer to the
union.
Here is a patch.
|
|
|
|
|
|
|
|
|
|
match glibc's quotient truncation behavior.
|
|
Port the generic optimized string funcs from glibc, with some tweaks
to cut their size a little. The main change is making memmove
call memcpy for forward copying to trim redundant code.
Make use of both the generic and arch-specific speed-optimized string
funcs configurable. Arch-specific take precedence over generic,
and generic takes precedence over basic size-optimized uClibc funcs.
|
|
|
|
|
|
Requested by Peter Mazinger. Testing wanted.
|
|
- adjust licensing terms of sources for crt*.o
- change the stat ABI to speed it up, matching changes in the kernel
- assorted bug-fixes, improvements and updates in the FR-V port
etc.
|
|
this was sent earlier in a different form:
http://www.uclibc.org/lists/uclibc/2004-January/008136.html
find attached a smaller version ... perhaps adding a fprintf to stderr before
calling abort would be nice like in the glibc patch, but whatever
glibc has since adopted a similar fix for their malloc (third hunk, line 1970)
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/malloc/malloc.c.diff?r1=1.121&r2=1.122&cvsroot=glibc&f=h
-mike
|
|
i sent this earlier but perhaps people missed it the first time around :)
http://www.uclibc.org/lists/uclibc/2004-August/009544.html
basically if you try to #include <sys/ucontext.h> on arm it'll fail because
ucontext.h utilizes typedefs found in bits/sigcontext.h ... i386 already has
this fix in uClibc
find attached a trivial patch to fix this
-mike
|
|
Below is a patch to make the pread and pwrite calls work on the SH
architecture. I've only tested this on the SH4 with a 2.4.24 kernel - a
fairly recent kernel is required as the problem is partially fixed in
the kernel itself. For more information (in relation to glibc, but the
problem is the same) see the thread at
http://sourceforge.net/mailarchive/message.php?msg_id=2375908
Someone should really test this on the SH2/3...
|