Age | Commit message (Collapse) | Author |
|
|
|
I've noticed a few people have posted over the last year about problems
compiling programs that use vfork when pthreads are involved. Some
detective work turned up that ptfork.c aliases vfork to fork and then tries
to call the original fork as __libc_fork. This patch removes the aliasing
when there is no MMU present, and uses the same call semantics to call
__libc_vfork. I then added a symbol to the m68k vfork.S to allow vfork to
be called as __libc_vfork.
The same bug exists in the uClibc CVS, and with a possible tweak this patch
should go through there as well.
Obviously, all other platforms need __libc_vfork as a workable means to call
vfork in order for this to work for them.
Let me know if there are any problems with this patch.
Art Shipkowski
Videon Central Software Engineer
(814)235-1111 x307
|
|
|
|
|
|
|
|
|
|
|
|
|
|
function not implemented".
|
|
|
|
we were unable to switch back to the original saved group/user ID.
-Erik
|
|
|
|
|
|
|
|
Also fix a dst-related bug which caused the use of uninitialized data.
|
|
they have not yet been opened.
My last try was completely and embarrasingly broken.
-Erik
|
|
|
|
Remove the ADD_LIBGCC_FUNCTIONS option and do things the right way.
Either we have a shared libgcc available, or the libgcc routines
aren't PIC and don't belong in the shared libc anyway.
|
|
fail if you had not previously called setpwent() or setgrent()
respectively. Oops. My bad.
-Erik
|
|
|
|
|
|
stop applying patches by hand...
|
|
select for older 2.0 kernels where poll is missing.
|
|
fpu_control.h header file, since the correct arch specific one was
always later overwritten by the generic one. oops.
-Erik
|
|
cause gethostbyaddr_r to keep looping allocating more and more
memory each time till alloca finally caused a segfault. Ugh.
This fixes that as well...
-Erik
|
|
ln.patch:
* Define $(LN) as ln in Rules.mak.
* Change all occurrences of ln into $(LN).
* Change all constructs like (cd path && ln -sf foo/file file)
into $(LN) -sf foo/file path/file. The latter construct is
already used in a number of places so it should not be
an additional compatibility problem.
|
|
rm.patch:
* Define $(RM) as rm -f in Rules.mak and test/Rules.mak
(this is the same definition as gmake uses by default).
* Change all occurrences of rm and rm -f into $(RM).
|
|
install.patch:
* Define $(INSTALL) as install in Rules.mak.
* Change all occurrences of install into $(INSTALL).
* Change all occurrences of mkdir -p into $(INSTALL) -d.
install -d is already used in a number of places so
this should not be an additional compatibility problem.
|
|
|
|
|
|
|
|
|
|
Code formatting cleanup.
|
|
I've created a patch for adding dn_expand() to uClibc 0.9.21.
dn_expand() is used by at least ipsec-tools and also openldap I think.
|
|
contributed by John Williams <jwilliams@itee.uq.edu.au>
|
|
|
|
export it,
|
|
reentrant, since there was still a shared static value. indent stuff,
|
|
Here's a patch... Since they aren't SUSv3 functions, I don't know if
they'll ever get officially added, but it helps with BSD porting and
allows quite a few Gentoo ebuilds to compile without changing anything.
Rob
|
|
I found inappropriate data types are used in some places in networking
codes.
* tcp_seq is 32bit (u_long -> u_int32_t)
* in_addt_t should be used for internet address (unsigned long -> in_addr_t)
* socklen_t should be used for accept()
This is a patch against uclibc-0.9.21 (can be applied for current
CVS). 64bit platforms (sizeof(int)!=sizeof(long)) will need this. I
believe this patch does not harm any 32bit platforms.
|
|
Current uClibc contains only one fpu_control.h and it is i386 version.
This is a patch to use platform specific fpu_control.h. All new files
come from glibc 2.3.2. This patch is against 0.9.21 but also can be
applied to CVS as is.
|
|
workaround a toolchain specifi bug for the e1.
|
|
|
|
yet, but should work...
|
|
expected thing. A so called "D'oh!".
|
|
wchar support is enabled.
|
|
their alignment are correct.
|
|
encountering EOF changed with Defect Report #141. In the current
standard, the stream's EOF indicator is "sticky". Once it is set,
all further input from the stream should fail until the application
explicitly clears the EOF indicator (clearerr(), file positioning),
even if more data becomes available.
Fixed a bug in fgets. Wasn't checking for read errors.
Minor thread locking optimizations to avoid some unnecessary locking.
Remove the explicit calls to __builtin_* funcs, as we really need to
implement a more general solution.
|
|
I got my mind fixed in one mode and didn't comply with the standards.
Things should be fixed now, but comparision testing is difficult when
glibc's scanf is broken and they stubbornly refuse to even acknowledge
that it is... even when confronted by specific examples from the C99
standards and from an official C standard defect report.
|
|
|