MIME-Version: 1.0
References: <CAGFcrM=KPg5AZie-ux055SVAZu08EmSJ3s-Q_Map5j5CmGaaKA@mail.gmail.com>
 <87bkum1div.fsf@ungleich.ch>
In-Reply-To: <87bkum1div.fsf@ungleich.ch>
From: Tomas Kolda <koldat@gmail.com>
Date: Tue, 21 Jun 2022 14:20:32 +0200
Message-ID: <CAGFcrM=YLSnEwOWsRc0krE68HdQL2QvUALs1-PDZaCPyrkYoDw@mail.gmail.com>
Subject: Re: Native Alpine GLibc support (NEW)
To: ~alpine/devel@lists.alpinelinux.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=C3=BAt 21. 6. 2022 v 13:07 odes=C3=ADlatel Nico Schottelius
<nico.schottelius@ungleich.ch> napsal:
>
> - a) Adding glibc support as an add-on/additionally to musl
>      While some things need to be clarified (which is libc.so...), most
>      things could stay the same and there would simply be an additional
>      libc installed and available.
>
>      Using this approach there might be *some* packages which are
>      available as -glibc variants (like a JVM), but most of Alpine would
>      stay as-is.
>
I am not sure it is possible to have it in a stable way. There are
more projects trying to achieve it. Some bring libraries from other
distros (sgerrand), some does compatibility layer (gcompat). In both
cases it is not 100% same so all applications does not work. First
does not work when you dynamically want to use other library from OS
that is musl. The other does not work when it relies on exact
functionality as it is only proxy. Some functionality also relies on
"headers" as well that affects it during compile time. That is why I
tried (b).
>
> - b) Replacing musl with glibc
>      This would be more the scenario of a "fork" or "glibc version" of
>      Alpine. All packages would need to be compiled, similar to adding a
>      new architecture, but potentially doubling the builds.
>
>      This might be more coherent and easier to understand and
>      potentially less confusing, if you only have software linked
>      against *one* libc.
>
Yes that is what I propose. To have a new "architecture" build that
will simply have everything with glibc enabled. That is what we do. We
have Alpine build with CLIBC=3Dglibc. We have around 300 packages (what
we need) built with a full set of build tools (build-base + abuild +
apk-tools + git).
>
> Both variants come with their disadvantages, I personally would have a
> small a preference for (a), keeping Alpine simple and lean as is, but
> adding glibc support in case it makes sense.
>
I would prefer (a) as well in case it can work for 100% cases. I do
not know how to achieve it. Any try to mix these libraries end up with
a crash.