This is **not** the specific plan being followed now!!
This is (was) the starting point of this thread.
The links and general information here are relevant, most of the build details are not.
= = = =
*) Picked a build system to use
(Buildroot, v2014.05, see:
http://buildroot.net/download.html)
*) Leaving that local repo copy alone, clone it (disk-to-disk) into a workplace that can be easily sacrificed when things go really wrong.
*) If this isn't the first time using the above sacrificial clone, do:
make clean
*) Use the 'make menuconfig' command to select arch and toolchain options.
Here, I am using the 'Cortex-A8' selection, with EABIhf
Selected C++ support, since we want to support C++ sources.
*) Also selected:
Linux headers: 3.0 (I may have to change that, but that is as old as this version goes without patching it).
BinUtils: 2.23.2
gcc: 4.8.2
glibc: 2.19
*) Let Buildroot do its thing about creating this toolchain:
make toolchain
*) Now, to funky up the build system options to create binaries that reference our (hard float) dynamic loader and hard float libraries (which will live in USB storage).
make menuconfig
Set the "Target Linker Options" to this god-awful looking thing:
Code:
-Wl,--dynamic-linker=/mnt/us/extensions/system/lib/ld-2.19.so,-rpath=/mnt/us/extensions/system/lib,--enable-new-dtags
The short version of "why" - -
When the kernel is told to run an executable, it:
Reads the executable's header and finds that it is dynamically linked -
Then it reads the header to find out what dynamic loader to use (our hard float dynamic loader: ld-2.19.so, not Amazon's old soft float dynamic loader) -
The kernel then loads and runs that dynamic loader, passing along the information on what should be loaded and run.
Yup - thats it, the kernel never "runs" the executable you requested, it only runs the dynamic loader and lets ld.so worry about the details.
*) Build a dynamically linked BR application (Busybox, since it is already set-up by default):
make busybox
*) Use readelf to see if things are looking at least reasonable:
Code:
core2quad bin $ readelf -dl busybox
Elf file type is EXEC (Executable file)
Entry point 0xdbd0
There are 8 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
EXIDX 0x092a20 0x0009aa20 0x0009aa20 0x00008 0x00008 R 0x4
PHDR 0x000034 0x00008034 0x00008034 0x00100 0x00100 R E 0x4
INTERP 0x000134 0x00008134 0x00008134 0x00029 0x00029 R 0x1
[Requesting program interpreter: /mnt/us/extensions/system/lib/ld-2.19.so]
LOAD 0x000000 0x00008000 0x00008000 0x92a2c 0x92a2c R E 0x8000
LOAD 0x093000 0x000a3000 0x000a3000 0x00782 0x02a3c RW 0x8000
DYNAMIC 0x09300c 0x000a300c 0x000a300c 0x000f8 0x000f8 RW 0x4
NOTE 0x000160 0x00008160 0x00008160 0x00020 0x00020 R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4
- - - -
Dynamic section at offset 0x9300c contains 26 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000000f (RPATH) Library rpath: [/mnt/us/extensions/system/lib]
0x0000001d (RUNPATH) Library runpath: [/mnt/us/extensions/system/lib]
0x0000000c (INIT) 0xb8c4
0x0000000d (FINI) 0x7d460
- - - -
A bit of background on that:
http://blog.tremily.us/posts/rpath/
And a correction, patchelf
**can** edit in a longer string:
http://nixos.org/patchelf.html
Note: that page needs a correction also, to the correct, current, form of the load flag options.
But, why all of this effort?
Because with our own hard float library and library loader, then all we need is patchelf and anything from the Debian ARMhf repository can be edited to run on "our" system.
**) Whoot!
Looking good so far.
Now just need to do some file location mangling and test if it works.
(Probably not, this is the 'pre-alpha' test stage and I most likely missed some critical details.)
Then, once the above (pure C source) is working, get the C++ stuff working.
A nice little summer project.