| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
libc_hidden_proto from old version
|
|
Makefile.in, disable __res_state, unavailable in resolv.h
|
|
|
|
of latest glibc version
|
|
import glibc updates) while keeping the few bugfixes ... idea is to keep both old and new linuxthreads around so we can hack on the new version while delivering the old stable version to end users
|
|
|
|
|
|
not exist, we reinclude the including Makefile. Moved arch/common fpu_control.h link creation into main Makefile.in. Updated the link creation script to remove all the other Makefiles
|
|
to _dl_setup_stack_chk_guard, as in glibc. SSP requires now binutils-2.16.1 and newer. Add NOT_IN_libc/IS_IN_libc. Began using -DSHARED in uClibc_main.c, there are more candidates in there. Move back dl_protect_relro to it's earlier place.
|
|
possible. Add clean targets for linuxthreads[_db].
|
|
archs lack proper crt1. The Makefiles in extra/scripts are intended to be linked into each dir, where it is necessary to build locally.
|
|
linuxthreads/sysdeps/TARGET_ARCH/Makefile.in proposed by vapier. The current implementation should suffice for now, but it needs to be extended for the nptl tree.
|
|
libc.so are rebuilt again if make is run a second time.
|
|
only once. Generalize all toplevel makefiles. Make sure, that libdl.so is built against libc.so and not libc.a
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
since we are going to support the two implementations of pthreads, we
again need to instead create symbolic links to use the proper version
of the file depending on the pthreads option chosen.
|
|
have to create symbolic links for 'semaphore.h' and 'pthread.h' which
will point to the proper pthreads directory. When we finish getting
NPTL working with uClibc, perhaps we can merge them, but a first glance
at the differences between the two does not make that very likely.
|
|
source tree.
|
|
|
|
a bit faster.
|
|
as the flags for all calls to 'as'
|
|
- 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.
|
|
Hi Erik,
I'm not sure why the NIOS support is not in uClibc -- perhaps the patch
was rejected or never submitted? In any case, I'm playing with some NIOS
stuff and created this patch against 0.9.26. The work was done by
Microtronix. I'm not sure who else contributed to it. It would be great
to have the NIOS support available in uClibc so developers don't have to
go searching for these bits.
Pete
|
|
This patch adds code to uClibc to support a new ABI designed for the
FR-V architecture, that enables text segments of executables and
shared libraries to be shared by multiple processes on an OS such as
uClinux, that can run on FR-V processors without an MMU.
Patches for binutils and GCC have just been posted in the
corresponding mailing lists. The binutils patch was approved,
but there's one additional patch pending review, that I posted
this week. An updated GCC patch will be posted to
gcc-patches@gcc.gnu.org as soon as I complete testing (I used a
known-good compiler to test the uClibc patch below).
Since the existing dynamic loader code didn't support independent
relocation of segments, it required changes that were somewhat
extensive. I've added a number of new machine-specific macros to try
to keep the platform and ABI-specific details outside the generic
code. I hope this is not a problem.
|
|
This patch adds the libpthread backend bits for sh64. As noted previously,
we can't inline things like the testandset() in pt-machine.h as we need to
use a completely different ISA / CFLAGS in order for this to work.
As a result, this patch is somewhat of a RFC as well to see what people think
of the libpthread/linuxthreads/sysdeps Makefile approach, etc. The approach
I've taken currently has been to provide a sysdeps/Makefile with a note that
TARGET_ARCHs that want build rules can simply add themselves into the list of
matching architectures to add to the subdir rule for. This probably isn't
the cleanest solution, but it's quite transparent and works quite well.
|
|
|
|
|
|
front.
|
|
|
|
|
|
from glibc 2.3. This should make threads much more efficient.
-Erik
|
|
|
|
|
