Yep - you are of course 100% right as per.
Didn't go into why this was handy for us.
Really should stop eliding things for the sake of clarity
Will indeedily keep my mitts on the SC
(and I have shoved it in the zip for good measure
Did my best to show my working out and configs.
Makes the job about 400% longer but meh, someone may actually need it one day.
Is it included in one of the standard thingies? possibly.
It's big world of thingies.
In other news - managed to hack together a working libglib2 - Will close the BR error. Basically it hates the older TC's. Will do a regression through the various chains until I find the break point and report it when the will to live is regained after 4 days of smashing my head against a brick wall.
On the plus side I HAVE learned a great deal about tracing through configure.ac's , configures and makefiles, also about gleaning lateral info from logs.
And, above all, observing the activities of and injecting automation into buildroot. Which was another "big" goal I have been working towards. It will be nice when I have enough understanding to compile a completed *solution*
Like this (that's the real-life buildroots link) - ideally with a couple of kindles as choices and all the relevant "Best-practice" TC advice annotated.
It's a huge task when I stand back and look at it. But meh. It will bring US closer to the exact, flexible, deliverable, repeatable, tools and mechanisms we want/need.
right down to creating microkernels, missing modules, low level device tools, file system bits, up through the available networking modules, and higher level softwares and on into the GUI level components, injecting new software, etc etc.
As you say it is all right there, with enough work.
Ah well time to bite the bullet and report the BR error as pebcak.
Someone dig me a hole to crawl into. thanks.