References: <CAGFcrM=KPg5AZie-ux055SVAZu08EmSJ3s-Q_Map5j5CmGaaKA@mail.gmail.com>
User-agent: mu4e 1.7.26; emacs 28.1
From: Nico Schottelius <nico.schottelius@ungleich.ch>
To: Tomas Kolda <koldat@gmail.com>
Cc: ~alpine/devel@lists.alpinelinux.org
Subject: Re: Native Alpine GLibc support (NEW)
Date: Tue, 21 Jun 2022 13:00:20 +0200
In-reply-to: <CAGFcrM=KPg5AZie-ux055SVAZu08EmSJ3s-Q_Map5j5CmGaaKA@mail.gmail.com>
Message-ID: <87bkum1div.fsf@ungleich.ch>
MIME-Version: 1.0
Content-Type: text/plain


Hey Tomas,

I have to say I find this an interesting idea, because at ungleich we
also sometimes have the need to run glibc based apps, which at the
moment, we simply run inside containers.

I see multiple paths here and before even diving deeper into the topic,
I would like to understand which one you are suggesting:

- 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.

- 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.

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.

Best regards,

Nico


Tomas Kolda <koldat@gmail.com> writes:

> Trying to send email again from my personal email as my previous post
> was marked as invalid.
>
> Hi,
>
> I know that this topic is very sensitive in Alpine, but please let me
> describe first what and why we would like to achieve.
>
> 1. We love to use Alpine for our containers. Alpine has very fresh
> versions packages, it is very easy to use, versatile, customizable and
> clean. Basically only superlatives.
> 2. Our applications are mostly Java. But many of our jars are JNIs and
> are compiled against glibc.
> 3. We were using Alpine with Glibc hacks like
> https://github.com/sgerrand/alpine-pkg-glibc It was working nice until
> we ran into a problem where some other library was trying to load
> other native library and it started crashing.
> 4. We have switched to native MUSL based everywhere (Java, libs,
> etc.). I was happy that it was possible, but I was surprised that the
> performance of our applications degraded a lot. Our application is
> heavily multithreaded. After long investigation I have found that
> degradation is because of poor implementation of pthread locks in
> muslc. Probably the advantage of glibc  is the adaptive locking
> feature and maybe other types of tunings. In our example application
> spends with muslc build 600% CPU  in kernel and 200% in user space,
> but on glibc 100% CPU in kernel and 700% in user space (where 100%
> means 1 CPU core). Yes it is that huge difference.
>
> At this point I had many options of what to do and one I would like to describe.
>
> - I started thinking that I would like to have a variant of Alpine
> with glibc. Everything else is the same and great as usual.
> - After the initial painful bootstrap to get bare minimum to be able
> to compile I got the first 300 packages built (enough for us) with
> only a few tweaks in some packages that are explicitly applying MUSL
> patches. I simply disabled these.
> - Now our application is running fast again with native builds and no tweaks.
> - I know glibc is maybe a little bit, but we simply need performance
> and compatibility.
>
> Example of change in procps. There is a tweak to make it work in MUSL
> so I simply conditionally disable it:
> if [ "$CLIBC" != "glibc" ]; then
> export LIBS="$LIBS -lintl"
> fi
>
> I would love to have the patches part of the main branch so I do not
> need to do merges from time to time. I can only dream that the Alpine
> community will provide the official build as well. I think that more
> people would like that when I look at a number of projects around
> hacking glibc in Alpine.
>
> Please do not take it as a heretical thought. It came as a need.
>
> What do you think about the project? I can share my changes in some
> branch or in github. I can also share initial 3.16 binaries to have an
> easier bootstrap. It was really a pain.
>
> Thank you very much for your project and the hard work you put into it.
> Tomas


--
Sustainable and modern Infrastructures by ungleich.ch