uClibc-alpine - Where we track our uclibc patches

	Commit message (Collapse)	Author	Age	Files	Lines
*	Final set of changes for NPTL and new build system. NPTL can now build with ↵	"Steven J. Hill"	2005-12-02	1	-104/+9
\| \| \| \|	the new build system.
*	Sync with glibc reference tree and changes for uClibc thus far.	"Steven J. Hill"	2005-11-16	1	-1/+2
\|
*	Fix up build system for NPTL. I admit it is much cleaner now, but I lost my ↵	"Steven J. Hill"	2005-10-04	1	-42/+58
\| \| \| \|	entire Saturday fixing this $!#$!#@$T! up.
*	Import latest 'clone' and 'vfork' functions from glibc. These have been ↵	"Steven J. Hill"	2005-09-03	1	-1/+1
\| \| \| \|	tested with the 'linuxthreads' thread model and normal uClibc using the included test suite. This puts me very close to having static NPTL applications working.
*	Rename 'fork.c' to be 'fork-nptl.c' because it ends up replacing the object ↵	"Steven J. Hill"	2005-08-17	1	-2/+2
\| \| \| \|	'libc/sysdeps/linux/common/fork.o' and 'fork' then appears as undefined when applications are linked against uClibc.
*	It occurred to me that for the uClibc way of doing things, we should be ↵	"Steven J. Hill"	2005-08-11	1	-0/+91
	using the syscall to fork if pthreads is not being used for NPTL, just like we do with the linuxthreads model. There were some name collisions that had to fixed, but things should be sane now. Also, due to complexities of the new thread model and compilation, the 'fork.c' from NPTL has to be compiled in with the C library, even though the code in it is not called until pthreads is linked in either dynamically by the loader or in a static binary. If that all makes sense to you, give yourself a cookie.