| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Peter S. Mazinger <ps.m@gmx.net>
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
Signed-off-by: Peter S. Mazinger <ps.m@gmx.net>
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
Signed-off-by: Austin Foxley <austinf@cetoncorp.com>
|
|
Signed-off-by: Austin Foxley <austinf@cetoncorp.com>
|
|
Final iteration to fix libc internal locking if libpthread is pulled
in by dlopen call (directly or indirectly).
We cannot really use the weak symbol trick for shared build, since
the symbols won't get refreshed if libpthread is pulled in dynamically.
In glibc, they have #ifdef SHARED magic to either use pthread_functions
table, or weaks. But as we shared object files with both builds, this
does not sounds good either.
The reintroduces the libc weaks.c, but uses them now only with static
build. For dynamic build, we still use the symbols with same name, but
provide weaks in forward.c so they end up dereferencing the
pthread_functions table indirectly if we are not linked to libpthread.
Mutex initialization is hard coded as inline, as it needs to happen even
if libpthread is not initially loaded.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: Austin Foxley <austinf@cetoncorp.com>
|
|
I semi-accidentally added include for libc-lock.h because the intention
was to use locking macroes from there. However, we ended up using using
the weak alias stuff. This is additionally good since now this can result
in compile errors like:
In file included from /toolchain/include/bits/uClibc_mutex.h:16,
from /toolchain/include/bits/uClibc_stdio.h:107,
from /toolchain/include/stdio.h:72,
from /work/freetype-2.3.11/include/freetype/config/ftstdlib.h:100,
from ./builds/unix/ftconfig.h:43,
from builds/unix/ftsystem.c:21:
/toolchain/include/bits/libc-lock.h:309: error: expected '=', ',',
';', 'asm' or '__attribute__' before 'void'
Remove the unneeded include causing breakage.
Reported-by: Kevin Day <thekevinday@gmail.com>
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: Austin Foxley <austinf@cetoncorp.com>
|
|
It is not possible to override for libpthread to override
the weak libc definitions. This has never worked in uclibc, and
does no longer work in glibc either (unless you use LD_DYNAMIC_WEAK).
The proper thing to do is have weak prototypes in libc, and
definitions in libpthread only. This way libc runs even if
those functions are not defined, but just needs to protect
against the NULL values (done by implementing __uclibc_maybe_call).
This fix the problems if libc is linked before libpthread or
if libpthread is pulled by a dependency library.
Signed-off-by: Timo Teras <timo.teras@iki.fi>
Signed-off-by: Austin Foxley <austinf@cetoncorp.com>
|
|
Signed-off-by: Austin Foxley <austinf@cetoncorp.com>
|
|
|
|
|
|
Leave the now obsolete libc/misc/pthread dir in for now.
|
|
|
|
|
|
though I still need to silence the warnings about _pthread_cleanup_push_defer
|
|
things, and avoid potential deadlocks caused when a thread holding a uClibc
internal lock get canceled and terminates without releasing the lock. This
change also provides a single place, bits/uClibc_mutex.h, for thread libraries
to modify to change all instances of internal locking.
|
