Bug 8756

Summary:	Dynamic Linker with Standalone Support breaks with LDSO_PRELINK_SUPPORT
Product:	uClibc	Reporter:	nixscripter <nixscripter>
Component:	Other	Assignee:	unassigned
Status:	NEW ---
Severity:	normal	CC:	uclibc-cvs
Priority:	P5
Version:	0.9.33.2
Target Milestone:	---
Hardware:	Other
OS:	Linux
Host:		Target:
Build:

Description nixscripter 2016-03-05 17:19:03 UTC

Back in 2014, there was an issue reported on the mailing with the dynamic linker on MIPS refusing to print any messages:

http://lists.uclibc.org/pipermail/uclibc/2014-January/048199.html

There was trouble recreating it, but I believe I have found the key: as alluded to on the mailing list, there is no _dl_dprintf anywhere in the MIPS architecture.

So how did it ever work? Well, apparently most people enable NPTL-style threads, and this definition in libpthread/nptl/sysdeps/generic/dl-tls.c makes it work:

#define _dl_malloc      malloc
#define _dl_memset      memset
#define _dl_mempcpy     mempcpy
#define _dl_dprintf     fprintf
#define _dl_debug_file  stderr
#define _dl_exit        exit

Whereas I have threads turned off:

HAS_NO_THREADS=y
# LINUXTHREADS_OLD is not set
# LINUXTHREADS_NEW is not set
# UCLIBC_HAS_THREADS_NATIVE is not set

And there is apparently no _dl_dprintf, so it doesn't print.

I would submit a patch, but I don't know where would be best to add it.

And no, I cannot just enable threads because I have both target and toolchain problems that made me turn them off.

Comment 1 nixscripter 2016-03-05 17:53:12 UTC

Nevermind that. I'm not awake yet.

I think it actually has something to do with the way symbols are (not) exposed by libc. I'm still working on it.

Comment 2 nixscripter 2016-03-05 19:10:25 UTC

Okay, I've done a bit more digging, and it's not actually the standalone mode that's broken. If I disable prelinking:

LDSO_STANDALONE_SUPPORT=y
# LDSO_PRELINK_SUPPORT is not set

Then the message prints:

Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked `ld.so', the helper program for shared library executables.
This program usually lives in the file `/lib/ld.so', and special directives
in executable files using ELF shared libraries tell the system's program
loader to load the helper program from this file.  This helper program loads
the shared libraries needed by the program executable, prepares the program
to run, and runs it.  You may invoke this helper program directly from the
command line to load and run an ELF executable file; this is like executing
that file itself, but always uses this helper program from the file you
specified, instead of the helper program file specified in the executable
file you run.  This is mostly of use for maintainers to test new versions
of this helper program; chances are you did not intend to run this program.

  --library-path PATH   use given PATH instead of content of the environment
                        variable LD_LIBRARY_PATH

So that seems to be the issue