Release 2.38

[frol]

https://www.gnu.org/software/libc/

There have been several issues with 2.35:

• ERROR: gcompat-1.1.0-r4: trying to overwrite lib/ld-linux-x86-64.so.2 owned by glibc-2.35-r1. #208
• Getting segmentation fault after python upgrade #209
• Is alpine-pkg-glibc supports for latest alpine release 3.18 #204

Seems like simple release would resolve the issue: #204 (comment)

[sevmonster]

I built 2.38, feel free to use it:

echo 'https://storage.sev.monster/alpine/edge/testing' | sudo tee -a /etc/apk/repositories
wget https://storage.sev.monster/alpine/edge/testing/x86_64/sevmonster-keys-1-r0.apk
sudo sh -c '
  apk add --allow-untrusted ./sevmonster-keys-1-r0.apk
  apk update \
    && apk add gcompat \
    && rm /lib/ld-linux-x86-64.so.2 \
    && apk add --force-overwrite glibc \
    && apk add glibc-bin'

[frol]

@sevmonster Do you plan to maintain the package? I am maintaining the Docker image: https://github.com/Docker-Hub-frolvlad/docker-alpine-glibc

[sevmonster]

It is easy enough to build. I probably won't try to fix it if it breaks unless I need it.

Why not just build the package in the Dockerfile?

[frol]

@sevmonster I didn’t want to duplicate the effort and introduce my own bugs when the package is available, but at this point I will consider doing that

[sevmonster]

I built it myself for my own needs, and it really is easy to build and deploy. If you want something more reliable, it would probably be best to build the tarball yourself, pull it into the image, and extract it like the package build script does. It is more straightforward than building or finding a package and installing it.

[b01]

So I noticed that the glibc build docker image is set to GLIBC_VERSION=2.38 \ and also that the latest version 2.35-r1 was built on Apr 13, 2023. Which makes me wonder if 2.35-r1 is just 2.37 in disguise?

1. https://github.com/sgerrand/docker-glibc-builder/blob/main/Dockerfile#L4
2. https://sourceware.org/glibc/
3. https://github.com/sgerrand/alpine-pkg-glibc/releases/tag/2.35-r1

[wmbin]

I built it myself for my own needs, and it really is easy to build and deploy. If you want something more reliable, it would probably be best to build the tarball yourself, pull it into the image, and extract it like the package build script does. It is more straightforward than building or finding a package and installing it.

Hello, how to build apk?

[sevmonster]

https://github.com/sgerrand/docker-glibc-builder

[wmbin]

https://github.com/sgerrand/docker-glibc-builder

https://github.com/sgerrand/docker-glibc-builder

Actually, I want to know how to build the compressed package generated by docker-glibc-builder into an apk package.

[sevmonster]

https://github.com/sgerrand/alpine-pkg-glibc/blob/main/APKBUILD

[wmbin]

https://github.com/sgerrand/alpine-pkg-glibc/blob/main/APKBUILD

Thank

[oliverlockwood]

@sevmonster (or @sgerrand) I'm going down the path of building glibc myself. One thing that I am struggling to reconcile is the size difference in the libraries between

• those in the Alpine packages this repo (used to) provide - e.g. libc.so.6 is 1.9 MB once you've installed the APK available at https://github.com/sgerrand/alpine-pkg-glibc/releases/tag/2.33-r0
• those that the related repo https://github.com/sgerrand/docker-glibc-builder provide, either as published artifacts (up to 2.37.0) or those you can build yourself - e.g. libc.so.6 is 19.5MB once you've unpacked the .tar.gz available at https://github.com/sgerrand/docker-glibc-builder/releases/tag/2.33-0

I am approaching this from a Java perspective, and I am not an expert on either the GNU C libraries, or on APK packaging, but the difference here is so significant - an order of magnitude in size! - I am sure I must be missing something (and yes, I have read the APKBUILD file).

Is there any chance that one of you may be able to help me to understand this, please?

[sgerrand]

As a quick pointer, the shared library file in the APK package is only one file out of the many contained in the compressed archive that is built by that other repository. (That archive also has files related to documentation, executables and numerous other aspects of the "full" GNU C library.)

Alpine's package builder strips superfluous information out of compiled files. That's the main reason for the difference in size between those two files.

[sevmonster]

@sgerrand Are you planning to push a new release for new glibc? I have been using 2.38 since I built it last and haven't had any issues.

[sgerrand]

Are you planning to push a new release for new glibc? I have been using 2.38 since I built it last and haven't had any issues.

I'll push a new version tomorrow. Thanks for the nudge!

[sevmonster]

Great. May want to consider resolving the conflict with gcompat somehow too? See above.

[jhg03a]

Are you planning to push a new release for new glibc? I have been using 2.38 since I built it last and haven't had any issues.

I'll push a new version tomorrow. Thanks for the nudge!

Nudge again

[debiansid]

ttps://storage.sev.monster/alpine/edge/testing/x86_64/sevmonster-keys-1-r0.apk

how make my own keys.apk like yours

thanks

[sevmonster]

https://wiki.alpinelinux.org/wiki/Abuild_and_Helpers#abuild-keygen
https://git.alpinelinux.org/aports/tree/main/alpine-keys
https://git.sev.monster/aports.git/tree/HEAD:/testing/sevmonster-keys

[sevmonster]

I built 2.39, if anyone wants to use it.

[ctm8788]

Hi @sgerrand ,
Hope all is well.
nudging and hoping some new releases can be built.

[ghost]

@sgerrand

[unoexperto]

@sevmonster Could you please advise what could be the cause of the following issue with JDK ? I used your version of alpine-pkg-glibc package (glibc-2.39-r0) in the latest Alpine. And then I tried to use Oracle JDK 23 in it like this

wget https://download.oracle.com/java/23/latest/jdk-23_linux-x64_bin.tar.gz -O java.tar.gz
gunzip -c java.tar.gz | tar -xf - -C /opt && rm -f java.tar.gz
 /opt/jdk-23.0.1/bin/java --version

it segfaults with

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007124c8d06447, pid=30, tid=31
#
# JRE version:  (23.0.1+11) (build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.0.1+11-39, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xeaa447]  Thread::SpinAcquire(int volatile*, char const*)+0x7
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to //core.30)
#
# An error report file with more information is saved as:
# //hs_err_pid30.log
#
#
Aborted (core dumped)

[sgerrand]

@unoexperto: I strongly advise you to run your software in an operating system which is based on the GNU C library. This Alpine package is designed for use by advanced users and I believe that you'll be able to resolve your problem more rapidly by using an operating system which matches the software which you're trying to install and/or deploy.