Bug 193

Same problem here with uClibc-0.9.29 and some patches:
http://trac.freetz.org/browser/trunk/toolchain/make/target/uclibc/0.9.29

arch: mipsel (4kc)
binutils: 2.17.50.0.17
gcc: 4.2.1

Attached testcase prints out:
Mar 18 16:52:11 freetz user.info daemon_pthread_create: main - before daemon()
Mar 18 16:52:11 freetz user.info daemon_pthread_create: main - after daemon() before pthread_create()
Mar 18 16:52:11 freetz user.info daemon_pthread_create: thread running

Created attachment 157 [details]
Testcase

Perhaps following testcase is also related to this problem. Fails on same system.

Created attachment 159 [details]
Testcase Threaded "hello world"

Please confirm if this is a problem with the current release. Our time machines are broken currently, so fixing older releases is hard.

Should I try with linuxthreads_old or new? Don't know if this affects the testcases.
I will try newest release. But the result will be that the failures occur also. ;-)

libpthread.old (linuxthreads was never fully checked into the tree and thus is fundamentally broken)

you need to post all relevant information in the bug report.  references to other sites is a waste of time.

the usage of syslog() is not necessary and if anything, complicates things.

Created attachment 163 [details]
simpler daemon/pthread test code

when I run simpler daemon the output for this program is:

root@:~# main - going to pthread_create()
thread running


and never ends, my sistem has uclibc 0.9.30.1 with libpthread.old, for the others test have the same behavior. 

Attached strace of simpler daemon. Linked with uClibc-0.9.30.1.

Created attachment 169 [details]
strace of simple pthread test

Can I provide further information/details to speed up fixing this bug? Because it's very anoying...
No, I can't provide a patch. ;-)

the test case i posted is all the info that is required to reproduce.

if you really want to spend more effort, then it'd be helpful to bisect what introduced the problem.  0.9.28.3 works for me while 0.9.30.1 does not.  according to you, 0.9.29 also does not work ...

https://dev.openwrt.org/ticket/4809

Here is a pending ticket addressing this issue. The description ("... the last uclibc has a broken "daemon" function implementation. "daemon" calls a wrong "fork" function (libc instead linuxthreads version) breaking the pthread environment. ") seems to be correct but the attached doesn't fix the problem for me.
Perhaps you can give me a hint how I get this weak linking of (pthread's) fork working.

Build two i686 uclibc (0.9.28.3, 0.9.30.1) toolchains with buildroot today. I'm astonished to see the same problem here. Thought this is related to mipsel!?

(In reply to comment #16)
> Build two i686 uclibc (0.9.28.3, 0.9.30.1) toolchains with buildroot today. I'm
> astonished to see the same problem here. Thought this is related to mipsel!?
> 

I can not reporoduce this on alpine linux, x86, uclibc 0.9.30.1 + patches, linuxthreads.new. You might want to try some of the patches we use.

http://git.alpinelinux.org/cgit/aports/tree/core/uclibc

this appears to be caused by the hidden alias to fork().  libpthread has its own fork() symbol but because daemon() calls the hidden one, that isnt used.

this simple patch fixes things for me:

--- a/include/unistd.h
+++ b/include/unistd.h
@@ -761 +761 @@
-libc_hidden_proto(fork)
+//libc_hidden_proto(fork)
--- a/libc/sysdeps/linux/common/fork.c
+++ b/libc/sysdeps/linux/common/fork.c
@@ -21 +21 @@
-libc_hidden_weak(fork)
+//libc_hidden_weak(fork)

but this doesnt address static linking ... the same bug will be observed

The problem still occurs with uClibc-0.9.31. And I assume it will never be fixed for linuxthreads.old?