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

[Khem Raj]

On Tue, Nov 26, 2019 at 10:37 PM Adrian Bunk <bunk at stusta.de> wrote:

> 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.


Keeping rat holing and derailing conversation in mind this will be my last
reply to this thread

It’s an opensource project and if contributors stop contributing to musl
effort it will die on its own we do t have to install a kill switch. OE
philosophy is to be a distro builder not a distro that’s key differentiator
and all of these arguments are very distro centric mindset. We do ask for
keeping builds clean and help with servicing the part of project that
interests a person, so pitch in what interests and hopefully there will be
enough of us around to support OE



>
> 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.


And not many upstream packages are built and tested regularly with Os leave
aside writing size friendly code in their dev streams so perhaps someone
should help them provide help testing with Os things will get better


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


Why 4 and not 2 or 16 fact is it depends on usecase


>
> cu
> Adrian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20191127/fc6710cf/attachment.html>