[OE-core] Very large size of libraries in core-image-minimal rootfs

[Adrian Bunk]

On Tue, Nov 26, 2019 at 02:57:43PM -0800, Khem Raj wrote:
> On Tue, Nov 26, 2019 at 11:56 AM Adrian Bunk <bunk at stusta.de> wrote:
>...
> > > there are many other design considerations where musl might make more
> > > sense
> >
> > Which of these are not covered by linking only your application
> > with musl?
> >
> > It is not clear that all this outweights the constant pains of forcing
> > people to fix the steady stream of new musl issues for all recipes.
> >
> For a moment if you do not assume glibc == linux then
> Most of times issues are in application assuming wrong things from system.
> in cases where issues are

In general I consider portability a positive thing, but it is also 
legitimate when an upstream makes the decision to use everything
provided by glibc.

But this is not really relevant when discussing what kind of effort 
should be required from people contributing to OE - many build failures 
and work are a price OE pays for musl compatibility, and it can be 
questioned whether it is really worth spending scarce resources on that.

The effort is smaller and the benefits are clearer when supporting musl
only in a limited amount of recipes relevant for tiny systems.

>...
> > The combinations that are most relevant in practice are:
> > - normal: -O2 + glibc + systemd
> > - tiny: -Os + musl + busybox init
> 
> again its two of many combinations  with OE.

There are combinations that match common usecases, and there are 
combinations that don't match common usecases.

Development and testing effort is best spent on combinations that
match common usecases.

poky-tiny building with -O2 is weird.

> > Using musl with -O2 or with systemd is far from the primary usecase
> > of using musl for size benefits.
> >
> > The other advantage of -Os is that it is also useful for non-tiny
> > systems since the benefits scale with the size of the filesystem.
> > It is a nice knob to fix kernel or userspace space problems that
> > does not change the API or ABI.
> 
> perhaps, however, reducing code size is a design decision more than
> compiler switch problem. Throwing any code at the compiler and expecting
> it to optimize for a given vector is never optimal.

The compiler switch is part of the design decision, and on a tiny system 
you do often not have the luxury of picking only some size 
optimizations.

Tiny is when you have to squeeze bootloader, kernel and userspace 
together on 4 MB flash.

cu
Adrian