Hi,
I'm using uClibc based on 0.9.33 stable branch (uClibc-0.9.33.2), and
prelink on SH target until now works fine.
Follow the results i got on my SH4 target:
On 1/24/2014 4:00 PM, Yann Sionneau wrote:
Hello,
I am trying to get prelinking to work on a MIPS target.
I reproduced the issue on OpenWRT (master branch, using
uClibc-0.9.33.2) using the "MIPS Malta CoreLV board (qemu)" Target
System.
At first uClibc Standalone Support was disabled leading to this when
trying to run the dynamic linker as an executable:
root@OpenWrt:/# /lib/ld-uClibc.so.0
Standalone execution is not enabled
Then I enabled the following options in uClibc configuration:
LDSO_STANDALONE_SUPPORT=y
LDSO_PRELINK_SUPPORT=y
Afterward I get this when running the dynamic linker as an executable
which means the standalone support has been enabled successfully:
root@OpenWrt:/# /lib/ld-uClibc.so.0
root@OpenWrt:/#
Seems you have some wrong declaration of _dl_dprintf.
You should get:
root@arcidiaf:~# /lib/ld-uClibc.so.0
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
Then here comes the issue:
root@OpenWrt:/# LD_WARN= LD_TRACE_PRELINKING=1
LD_TRACE_LOADED_OBJECTS=1 /lib/ld-uClibc.so.0 /bin/busybox
root@OpenWrt:/#
root@arcidiaf:~# LD_WARN= LD_TRACE_PRELINKING=1
LD_TRACE_LOADED_OBJECTS=1 /lib/ld-uClibc.so.0 /bin/busybox
/bin/busybox => /bin/busybox (0x400000, 0x0)
libcrypt.so.0 => /lib/libcrypt.so.0 (0x29558000, 0x29558000)
libm.so.0 => /lib/libm.so.0 (0x2957d000, 0x2957d000)
libc.so.0 => /lib/libc.so.0 (0x2959f000, 0x2959f000) TLS(0x1, 0x8)
ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x52aac000, 0x52aac000)
This should (should it?) print the list of libraries that busybox
depends on (at least eglibc does that on x86), but here it prints
nothing.
However, if running directly busybox with those environment variables
I get what I wanted:
root@OpenWrt:/# LD_WARN= LD_TRACE_PRELINKING=1
LD_TRACE_LOADED_OBJECTS=1 /bin/busybox
/bin/busybox => /bin/busybox (0x400000, 0x0)
libcrypt.so.0 => /lib/libcrypt.so.0 (0x77c19000, 0x77c19000)
libm.so.0 => /lib/libm.so.0 (0x77bf4000, 0x77bf4000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x77bd0000, 0x77bd0000)
libc.so.0 => /lib/libc.so.0 (0x77b63000, 0x77b63000) TLS(0x1, 0x0)
ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x77c3d000, 0x77c3d000)
Unfortunately, the prelink tool seems to depend on the eglibc
behaviour which is to print those messages even if the dynamic linker
is called as an executable, therefore I get those errors when trying
to prelink:
root@OpenWrt:/# cat /etc/prelink.conf
-l /lib
-l /usr/lib
-l /bin
-l /sbin
-l /usr/bin
-l /usr/sbin
root@OpenWrt:/# prelink -c /etc/prelink.conf -C /etc/prelink.cache
--dynamic-linker=/lib/ld-uClibc.so.0 -mvR
--ld-library-path=/lib:/usr/lib -a
prelink: /bin/ubus seen 0 times in LD_TRACE_PRELINKING output,
expected once
prelink: /bin/busybox seen 0 times in LD_TRACE_PRELINKING output,
expected once
[...] etc
By looking at prelink source code (src/gather.c) I can see that indeed
prelink tries to execute "LD_WARN= LD_TRACE_PRELINKING=1
LD_TRACE_LOADED_OBJECTS=1 /lib/ld-uClibc.so.0 /bin/busybox" and then
tries to parse the output to get the dependencies:
For this the dynamic linker has been extended to support the standalone
mode.
argv[i++] = ent_filename;
argv[i] = NULL;
envp[0] = "LD_TRACE_LOADED_OBJECTS=1";
envp[1] = "LD_TRACE_PRELINKING=1";
envp[2] = "LD_WARN=";
envp[3] = NULL;
f = execve_open (dl, (char * const *)argv, (char * const *)envp);
Does anyone encounter this issue as well? Is there a known fix?
Thanks :)
PS: I am using prelink-20130503
So do I.
Regards,
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
