[OE-core] [PATCH 1/4] glibc: Remove site_config and glibc-initial

Mark Hatle mark.hatle at windriver.com
Fri Dec 21 02:22:27 UTC 2018


On 12/20/18 1:50 PM, Burton, Ross wrote:
> On Thu, 20 Dec 2018 at 18:02, Mark Hatle <mark.hatle at windriver.com> wrote:
>> As far as zlib/ncurses being the only things that augmented them, when this was
>> originally implemented many years ago -- those items were the most commonly used
>> by other configure scripts.  So adding those defaults when zlib and/or ncurses
>> was provided by the system offered a measurable difference in the performance of
>> configure.
> 
> Do you know what the zlib and ncurses siteconfig files were doing?
> Just short-circuiting the AC_CHECK_HEADER call, which is basically
> stat(includedir + header.h).  I'd call that the definition of
> premature optimisation. :)

In the original AC_CHECK_HEADER stuff, it was more then just a simple stat.  The
system would compile a small executable that included the header and then
attempted to execute a pass/fail -- or in the cross compile case would do
something with the output binary.

This very well may have changed from a compilation step to a simple stat in
configure in the the last 4 or 5 years.  It's that compilation/execution step
(both that and the various sizeof) that were hideously slow in the original
implementation and being avoided by the special contents.

The assumption we were making of course was that zlib, ncurses (or anything
else) actually worked with those headers.. so we skipped the compilation and
just did a stat based on the headers to fill things out.

The systems that did the sizeof and header identification in the site-config
bbclass were written to do things in a dynamic way so that if the system
behavior changed we wouldn't have incorrect defaults "until someone noticed".

The behavior of using the compiler to identify a sizeof and using tools to
return the result is actually very efficient -- but does require a functioning
compiler (and headers).  If I remember correctly, we're not fully compiling, but
putting out an intermediate object which we can then query for the values of the
various pieces.  (In one iteration at least, we processed all of the sizeof in a
single pass making it even more efficient.)

--Mark

> Ross
> 



More information about the Openembedded-core mailing list