Bug 14096

Summary: [suggestion] move functions in libm (e.g. isnanf) and libpthread into libc.so like glibc
Product: uClibc Reporter: WangXu <wangxuszcn>
Component: OtherAssignee: unassigned
Status: RESOLVED DUPLICATE    
Severity: enhancement CC: uclibc-cvs
Priority: P5    
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Host: Target:
Build:

Description WangXu 2021-08-09 07:39:54 UTC
There's always problems with underlinking and symbol versioning.
for example, the patch of CVE-2013-0340 for expat introduces isnanf(), which belong to libm in uclibc, not the way like glibc. we got complie error.

suggest that,we move functions in libm (e.g. isnanf) and libpthread into libc.so , like glibc libpthread removal project.

Reference:
https://sourceware.org/legacy-ml/libc-alpha/2019-10/msg00080.html

From: Florian Weimer <fweimer at redhat dot com>
To: libc-alpha at sourceware dot org
Date: Fri, 04 Oct 2019 11:57:28 +0200
Subject: libpthread removal project
One of my long-term goals is to remove libpthread and move everything
into libc.  The remaining library will just be stub, and maybe contain
some compatibility data symbols (if we have any by then).

My motivation for this is that we continue to have problems with
underlinking and symbol versioning.  For example, users forget to link
against librt and therefore get the compat definition of timer_create at
run time.  Another example is libstdc++, which uses an unversioned
reference to pthread_create, which is bound to the compat definition of
pthread_create.  (This only works because libstdc++ doesn't pass any
thread attributes.)

Some libraries (including libstdc++) use weak symbol references to
detect the presence of libpthread.  If libpthread has not been loaded,
they assume that they do not have to use atomics for updating counters
etc.  After libpthread removal, this optimization no longer works.  This
is why I plan to add the __libc_single_threaded variable as a
replacement, which will continue to work for detecting single-threaded
processes once pthread_create or pthread_key_create are always
available.  (The not-linking-against-libpthread optimization is already
of decreased use today because a lot of single-threaded processes load
the library indirectly, so I think .)

Previous discussion:

  <https://sourceware.org/ml/libc-alpha/2019-08/msg00295.html>
Comment 1 WangXu 2021-08-09 07:42:53 UTC

*** This bug has been marked as a duplicate of bug 14101 ***