Sorry, nothing useful to report this morning - maybe latter.
- -
Edit: - -
When the automation fails you, re-invent the wheel:
Code:
configure:6680: checking for sysroot
configure:6710: result: /mnt/base-us/esys
This post would be the length of War and Peace if I told the story of getting that path from a block in the Buildroot menu system all the way into the configure log of an autotools package.
Maybe I learned something in the process.
- -
Edit: - -
Getting closer, the build running now might even be worth testing.
- -
Edit: - -
After a few false starts (and full builds) tossed due to typo's . . . .
I have something close enough to start looking at build bugs in the resultant binaries.
One of the big ones, this last build does not use -rpath - - -
Because some of the applications where already using it (they aren't suppose to be, but not everything has been patched (yet) ).
Instead, (eventually) everything will get a -sysroot set that places the new file system tree at /mnt/base-us/esys (rather than at "/").
This build run does (well, **should**) have everything requesting our own dynamic linker (which **is** a multi-library loader).
This combination is a bit 'strange' -
I don't think any of the distributions build an eabihf for ARMv6, their oldest arm supported for eabihf is ARMv7.
But this extension to my old "ARMhf on Kindle" project thread is intended to retrofit the K2, DX, DXG, and K3 (with maybe the K4 thrown in).
Later, another build, only optimized for the i.MX6 SoC's processor devices.
(running ARMv6 code on those is sort of a waste of time - literally).
Although just at the 'rough draft' stage - my changes to Buildroot-2015.08 release are attached.