March 2019 - devel - example.com

__dl_iterate_phdr includes main application binary in list
by Bogdan Harjoc 22 Mar '19

22 Mar '19

After building uclibc-1.0.31 with AddressSanitizer enabled (gcc7.3 and 8.2), asan complains at runtime that it's not the first library in the so-list. With a breakpoint on AsanCheckDynamicRTPrereqs which calls __dl_iterate_phdr, I see the first module that uClibc returns has info->libname = "/home/user/myapp", while on glibc-2.27, libname is an empty string. ASAN depends on seeing this empty string. Should __dl_iterate_phdr return an empty string here, or is there an alternative to get asan-enabled uClibc toolchains ? Thanks.

1 1

Re: [uclibc-ng-devel] [LTP] [PATCH] cpuset: disable for UCLIBC
by Vineet Gupta 18 Mar '19

18 Mar '19

On 3/14/19 3:01 AM, Petr Vorel wrote: > Hi Vineet, > >> libcpuset.c relies on FTS which is not enabled by default on uClibc. >> Instead of needing to reconfigure, rebuild uClibc lets disable this test >> for uClibc > Which uClibc version are you using? > Both uClibc and uclibc-ng has it [1] since 2011, version v0.9.32, in commit > a4aa01c12 ("Added fts support for traversing UNIX file hierarchies.") Right I'm using bleeding edge as well, and do have the header in sources, its just not configured/enabled by default hence not available in installation. > It's actually MUSL, what is missing it [2]. Although there is some > implementation [3], we should skip it for musl. But the clearest way is really > to check presence of <fts.h>, that's fix it for all libc. Spot on, that is indeed the best/ideal way of doing it. Do you know if such a mechanism already exists in LTP. If you point me to an example I can respin the patch accordingly. Thx, -Vineet

1 0

[PATCH] cpuset: disable for UCLIBC
by Vineet Gupta 12 Mar '19

12 Mar '19

libcpuset.c relies on FTS which is not enabled by default on uClibc. Instead of needing to reconfigure, rebuild uClibc lets disable this test for uClibc Signed-off-by: Vineet Gupta <vgupta(a)synopsys.com> --- testcases/kernel/controllers/Makefile | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/testcases/kernel/controllers/Makefile b/testcases/kernel/controllers/Makefile index 404073947904..9f4abe28bfcf 100644 --- a/testcases/kernel/controllers/Makefile +++ b/testcases/kernel/controllers/Makefile @@ -29,6 +29,11 @@ LIBDIR := libcontrollers LIB := $(LIBDIR)/libcontrollers.a FILTER_OUT_DIRS := $(LIBDIR) +# controllers/cpuset/cpuset_lib/libcpuset.c uses fts +ifeq ($(UCLIBC),1) +FILTER_OUT_DIRS += cpuset +endif + $(LIBDIR): mkdir -p "$@" -- 2.7.4

1 0

Problems with circular dependencies when trying to dynamically load a GStreamer plugin on Raspberry Pi / Buildroot
by avnerus 01 Mar '19

01 Mar '19

Hi! I've been having troubles loading a gstreamer plugin for Raspberry Pi (libgstrpicamsrc.so) on Buildroot with Uclibc-ng 1.0.30. It seems that some circualr dependencies are preventing the plugin from loading (specifically libmmal_core.so and libmmal_util.so). I noticed that GStreamer loads its plugins using RTLD_NOW, but shouldn't it still be able to handle circular dependencies? The plugin does load correctly on glibc. I'm attaching the output of the load using LD_DEBUG. There seem to be a lot of messages regarding circular dependencies. There is also a deeper analysis of the issue and how I eventually worked around it in here: https://wiki.avner.us/doku.php?id=embedded-web-interaction:uclibc-ng-proble… Would appreciate any insights, Thank you! /Avner

1 0