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

[Mark Hatle]

On 12/20/18 7:02 AM, Burton, Ross wrote:
> On Thu, 20 Dec 2018 at 11:59, <richard.purdie at linuxfoundation.org> wrote:
>> On Thu, 2018-12-20 at 11:50 +0000, Burton, Ross wrote:
>>> As the only users of siteconfig are now zlib and ncurses, should we
>>> just rip it out entirely leaving a gap for a fresh implementation?
>>
>> I'm cc'ing Mark who has a lot of the history on this.
>>
>> I think we're at a point where we likely need to re-implement this in a
>> different way...

I do think it's still needed/desired.  However, I absolutely agree we need to
rethink/reimplement the generation aspect of the site-config part.

> I did some poking at this a few weeks ago, basically turned off
> siteconfig by removing the 'inherit siteconfig' from
> autotools.bbclass.
> 
> Interestingly, at the time for core-image-minimal this actually
> resulted in the build being faster.  Some recipes were a little slower
> to configure, specifically coreutils had the biggest slowdown as it
> appears to probe for every syscall in the world (via gnulib) but that
> only took seven seconds longer.  However, as the siteconfig generation
> is done by writing a custom configure.ac and then doing the
> autoconf/configure dance, these slowdowns were balanced out by glibc
> taking an extra 30 seconds.
> 
> It appears that disabling siteconfig for glibc is an acceptable
> compromise if we can not build glibc and gcc twice.

glibc is something we've never been concerned with 'doing the wrong thing'.
It's also very possible that we could use glibc's autoconf output as a basis for
the site-config items.

Before the way the system worked is that it tried to determine the 'stupid
defaults(*)' that autoconf is always looking for, as well as many of the
syscalls/headers that are common.

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.

We expected over time additional things would be added (but obviously they never
were).  Stuff like gnome, glib, etc...


So my recommendation is that the siteconfig is something (new recipe) that
either runs right after the system libc (and everything else depends on that
uses autoconf) -- or runs at the end of the libc command.

The goal of this is to provide a core set of system wide definitions in a way we
know will produce a consistent set for any autoconf user.  (If other systems,
like cmake could make use of this type of thing -- it's something to consider as
well.)

We also still want a way that manual definitions can be setup on a global basis
for a given architecture.  (We do want these limited for the most part, since
maintenance is overlooked -- but we've certainly seen cases in the past where
configure works like this:  Yes, No, Cross -- where cross defines 'No' and never
checks.   This functions, but ends up in a significantly less optimized
situation, and these are incredibly difficult to identify.  [Using QEMU isn't an
option, as QEMU doesn't know -all- potential architectures...]

* stupid defaults - sizeof char, short, int, long, void, long long, etc...


Anyway, my 2 cents.  I'd like to see how this goes with it stripped out for the
next few weeks.. and I'll back back early January where we can evaluate my
assumptions/experiences above and see how this tracks with current reality.

--Mark

> Ross
>