Perhaps this will be of interest to those following this building of a system update.
We want to do graphics for our clock page (which will actually be a *.png picture).
All Kindle models can display a *.png picture (their messages and screensavers are *.png).
And we need to generate a new *.png each time the time-of-day changes.
Whoot!
We (or a script) requests the Lua application.
The command line processor turns that request over to the kernel.
The kernel reads the file header and finds the application is dynamic so it loads the loader (ld-linux-armhf.so.3 - which is a static binary) and turns over the request for it to handle.
The kernel "knows" what loader application because the application "told" it in the header's .interp field.
(In this case, it tells it the wrong one - I need to 'fix' the Lua makefile.)
The following is the information the loader uses to create the memory image:
Code:
usr/bin $ objdump -xs lua | grep '\.interp\|NEEDED\|SONAME\|RPATH'
NEEDED liblua.so.5.1.5
NEEDED libm.so.6
NEEDED libdl.so.2
NEEDED libreadline.so.6
NEEDED libhistory.so.6
NEEDED libncursesw.so.6
NEEDED libc.so.6
0 .interp 00000019 00008134 00008134 00000134 2**0
Contents of section .interp:
The dynamic loader checks if each of the above are already in memory and reuses it or if not, loads it.
Looking at the first library requested as an example, the only thing it needs is libc - which you can bet is already in memory.
Code:
usr/lib $ objdump -xs liblua.so.5.1.5 | grep '\.interp\|NEEDED\|SONAME\|RPATH'
NEEDED libc.so.6
SONAME liblua.so.5.1.5
The dynamic loader (unless horribly broken) reused the copy of libc that was already loaded.
After that, and the loading of everything else needed, the loader turns execution over to Lua.
Which, when processing its script, finds a:
lc = require 'luacairo'
statement in the script.
The processing of the "require" statement discovers that it needs an external dynamic library, so it calls the dl (dynamic loader) library to get that done.
The dl library, not to re-invent the wheel, loads a copy of the system loader to handle whatever requests it gets.
Code:
lib $ objdump -xs libdl-2.21.so | grep '\.interp\|NEEDED\|SONAME\|RPATH'
NEEDED libc.so.6
NEEDED ld-linux-armhf.so.3
SONAME libdl.so.2
In this example case, it loads the libcairo dynamic library.
At this point, things are going to crash and burn if they haven't already.
Code:
lib $ objdump -xs libcairo.so.2.11400.2 | grep '\.interp\|NEEDED\|SONAME\|RPATH'
NEEDED libpixman-1.so.0
NEEDED libfontconfig.so.1
NEEDED libexpat.so.1
NEEDED libfreetype.so.6
NEEDED libharfbuzz.so.0
NEEDED libglib-2.0.so.0
NEEDED libpthread.so.0
NEEDED libbz2.so.1.0
NEEDED libpng16.so.16
NEEDED libz.so.1
NEEDED librt.so.1
NEEDED libm.so.6
NEEDED libc.so.6
SONAME libcairo.so.2
RPATH /var2/k2-work/k2-rel/./host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/lib:/var2/k2-work/k2-def/./host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/lib
See all those required dynamic libraries?
Those have to be found and loaded.
Only the run-time search path is set to locations that only exist on my build machine, not on the Kindle. (Oops)
Obviously, I have to 'fix' the libcairo makefile also.
And probably throw in a few more build system 'tweaks' to stand a better chance of getting things correct the first time the binaries are built.
And the first 'tweak' will be to fix its infrastructure of macros that are (mis-) using a 'reserved' variable name (LDFLAGS) to pass extra flags to GCC rather than to LD.
Ah, I guess the invented name(s) for that field will be based on: "GCCFLAGS"
Since that is how they are using it.
= = = =
@idoit: The binaries associated with Wireshark have the same set of problems.