MIME-Version: 1.0
From: Tomas Kolda <koldat@gmail.com>
Date: Tue, 21 Jun 2022 09:32:44 +0200
Message-ID: <CAGFcrM=KPg5AZie-ux055SVAZu08EmSJ3s-Q_Map5j5CmGaaKA@mail.gmail.com>
Subject: Native Alpine GLibc support (NEW)
To: ~alpine/devel@lists.alpinelinux.org
Content-Type: text/plain; charset="UTF-8"

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