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.
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.
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