| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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
|
