| Age | Commit message (Collapse) | Author |
|---|
|
For noMMU targets we need a pthread_atfork dummy, otherwise
libraries like libressl using pthread_atfork, but not fork()
for itself, can not be used. But software like curl with
ssl support linking against libressl still work fine on noMMU
targets.
|
|
There is not possible to use use fork() on noMMU target, so exporting
pthread_atfork() for such target is useless.
A program using pthread_atfork() will likely fail at runtime due to the
error code returned by this function.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
|
|
Linuxthreads.new isn't really useful with the existence
of NPTL/TLS for well supported architectures. There is no
reason to use LT.new for ARM/MIPS or other architectures
supporting NPTL/TLS. It is not available for noMMU architectures
like Blackfin or FR-V. To simplify the live of the few uClibc-ng
developers, LT.new is removed and LT.old is renamed to LT.
LINUXTHREADS_OLD -> UCLIBC_HAS_LINUXTHREADS
|
|
This reverts commit 6b6ede3d15f04fe825cfa9f697507457e3640344.
|
|
|
|
Keep only fork (and it's hidden variant) and __libc_fork.
Common __libc_fork prototype in unistd.h.
Get rid of __fork, by changing HIDDEN_JUMPTARGET(__fork) to use fork
I can't see the reason to have fork() in libpthread, but kept it for now
making __fork static in these files.
Signed-off-by: Peter S. Mazinger <ps.m@gmx.net>
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
|
|
|
|
|
|
of latest glibc version
|
|
The vfork() wrapper defined in libpthread, that's used to run
pthread_atfork()-registered handlers, is not only a very bad idea,
it's broken and useless. Here's the rationale:
[---------snip----------]
Since the implementation as it stands is broken (linking a program
that vfork()s and exec()s on the child and wait()s on the parent works
unless you happen to link with libpthread), and I can't think of
any workable solution, I suggest that we simply remove the vfork()
overrider in the non-MMU case. Yes, we might lose some small amount
of functionality here, but it's not like people running uClinux expect
anything resembling actual fork() to work.
|
|
|
|
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
|
|
glibc 2.1.3 and ported to work with uClibc by Stefan Soucek and Erik Andersen
(me). Stefan has hacked things up such that linuxthreads runs on MMU-less
systems (tested only on arm-nommu). Erik cleaned things up and made it work
properly as a shared library.
-Erik
|
